Looking for golang developer with experience in tourism
Within the tourism sector and, especially in hotel distribution, the integration with suppliers with the purpose of receiving their products as well as distributing own products it is a quite habitual situation and includes the participation of multiple agents. In this environment we have an application that is in production in some of its phases and in development in others.
Therefore the purpose is realizing the integration between the own environment and accommodation providers’ APIs in order to increase product database and as a result being able to sell online with real time prices and availability.
What do we require?
We request a budget for the completion of the task described in this document taking into account the technical requirements requested by us and knowing the integration information that the supplier/client offers. It will be possible to request additional information of technical aspects of our application prior to the definitive economic issuance of the offer.
Budget modifications won’t be accepted caused by different requirements, so it will be the offerers responsibility to review the documentation and request before the extension of information that will be needed for the correct evaluation of the dimension of the work to be done. Budget proposal contains:
Brief summary of previous work done in GO and / or in the tourism sector.
Deadline for the completion of the work.
Number of people assigned to development.
The use of Git version control system is required. We will have a copy of the code on GitHub for read only. The main and daily work won’t be done with direct commits or pull requests, we will use Gerrit.
Gerrit is a code review tool that starts from Google where each individual commit can receive comments and be improved before someone with permits approves and send to master as one more commit.
The commits that are developed during this work will be subject to approval by our programmers before joining them and being able to request changes or modifications in things like (without being exhaustive) the organization of the code in functions, the names of variables, the commit message, the implementation as such or increase the optimization. With this objective it will be necessary to carry out the work in small increments easy to review and analyze to streamline development. These changes are oriented to facilitate our subsequent maintenance of the code.
All codes, including function names and variables, must be programmed in English.
Comments can be Spanish or English, depending on which is better for programmers’ communication. There will be a small pre-training of the code style in other parts of the project to make the adaptation easier and smoother. No unit tests or a code-specific coverage are requested beyond the Gerrit code review itself.
We need to make two new packages in the Go programming language. All the codes that we unite will of course be formatted with gofmt and will pass the code review of people who take more time in the project.
Hotels do not usually make a direct sale in each and every one of the websites as booking.com. In the sector there are a lot of methods to resell rooms, and suppliers that are completely dedicated to buying rooms and offer them with an API, so you can reserve them or distribute that availability and price. They are also responsible for managing that once the reservation is made, the availability of the room is reduced and payment, previous discount of the commission, get to the hotelier. We integrate with several suppliers. The task is to create a library that implement the integration with supplier/client.
Some suppliers/clients do offer an XML API document in a PDF that is delivered to implementers and might be attached to this document.
To unify the different providers/clients, a common interface defined in Go is used, which is implemented in each library on both sides with the operations that we require for our application. The implementation has three parts that we detail below:
1. On the one hand we must download the supplier’s hotel catalogue. To avoid
unnecessary requests we keep a simple cache (key, value) with the responses of the hotels to be able to reindex them with new data every time we want/need. The objective is to fill this cache by implementing the appropriate methods of the interface that we provide.
2. We have some structures (models and SQL tables) that store the data from all providers. The goal is implementing supplier’s mapping from supplier’s requests to the
model, through the guidance we give with the interface. It will be necessary to carry out the previous study and the proposal of possible correspondences, validated by the project management.
3. The last part is the request for availability and confirmation of the reservation.
When a user makes a request to reserve, the implementation will take care of responding which hotels are available with the supplier and for which price and terms and conditions. In addition, if the user initiates the reservation, he must confirm with the supplier the exchange and secure the reservation. Again this will be done by implementing the appropriate methods of the interface that we provide.
We also have a special requirement: we deploy our servers on the PaaS Google App Engine standard service (Go 1.8). In practice and in what may affect programming means that we can not do any of the following actions:
1. Write files on disk.
2. Connect directly to the database.
3. Open requests to external APIs through HTTP.
Any of the tasks mentioned above must be oriented towards using the service that Google provides for this purpose to improve scalability. This mainly supposes three things, one for each of the limitations:
1. We can not write to disk. The import cache will also be saved in the database with techniques that we have already prepared with other providers to such an effect with which we interact thanks to the interface.
2. The connection to the database is made through an own public language library that works by using database / sql package of the standard library. The use of the library prevents that you have to write any SQL. The introduction of SQL in code reviews is not permitted.
3. Being such a concretely implemented API by so few companies, there is no open client, and less on Go, that we could use. Even so, it is most likely that neither can we use it for the requirement of using the App Engine API to HTTP requests to external services. Therefore you have to make a thin client language to connect to supplier’s service.
The idiomatic client will consist of:
A Client structure that stores certain important information such as access credentials or the URL of the endpoint.
One or more private call methods that abstract the serialization procedure and error processing during calls to the external service and the urlfetch configuration procedure (the App Engine API for requests external).
Public idiomatic methods that we can use from the outside to interact with the supplier’s API.
The client/supplier must be light in the sense that we do not need (nor should we) implement properties or methods that we do not use for the task.
Certain errors such as lack of availability, prices that change or other necessary
must be used both in the client/supplier and in the implementation of the interface to be able to recognize and treat them throughout the process. The errors must be in accordance with the errors that return the rest of implementations.
We attach the documentation provided by the supplier/client for the integration, for a
possible preliminary exploration of the task.
3 freelancere byder i gennemsnit €3694 på dette job