Hello!
Hello! My name is Rodrigo Ramirez; I'm a Full-stack developer, entrepreneur, and Argentinian. I have been living in Tokyo, Japan, since 2014.
I'm working as a Backend lead engineer at ReiwaTravel, and together with an amazing team, we are trying to unlock many of the limitations that the current travel industry has by digitalizing many of the processes and having more control from our side about the experiences we deliver to our customers.
In this article, I will explain the behind scenes of how we are achieving this from a technical perspective.
If you want to know more about me:
What are we building?
From the point of view of an backend engineer, two big parts have to be built, the first one is the business side, and the second one is the customer side.
(*) simple representation of the system.
① Business Side (internal side)
We need to create a system that aggregates many different providers (hotels, flights, activities, etc...), and it includes their availability and pricing.
② Customer Side (public side)
We use the information collected from the different providers to design the tour packages that our customers will see and book.
Context
For more detailed information about our business, please refer to the articles written by our PDMs.
Challenge
As an initial phase (MVP), completing the integrations with each one of the providers to aggregate their data inside our system is a challenge that requires time, people, contracts, etc.
But the most important is a well understanding of the travel industry and their players to build our system correctly and design the tours that our customers will see and book.
Choosing the right technology stack
At the beginning of the project, there were many unknowns around how our system should be to support all that we wanted to do. (even now, it is still not 100% clear)
But at the same time, we had to start building something, so we decided to start building from what we knew.
As a startup in their initial phase, the most important is to focus on the product and the speed to deliver that product to our customers to learn during the process until we find that sweet spot called Product-market fit.
① Company
Current team knowledge: You can't start using new technology without trying it before. Having the confidence to deliver a product to our customers and solve any technical challenge is essential. Unknowns will slow down the development speed.
② Market
Developers available using that technology: When your product grows, you will need to hire more developers. The available developers with professional experience using that technology are an important factor.
Future proof: If the technology trend is declining, it may lose interest for the developers, making it difficult to hire the good ones because the company will look less attractive to them.
③Technology
Development speed: After knowing what has to be built, you need to choose the technology that better fits it and allows you to quickly deliver a product to our customers. Reducing the number of technologies used and complexity will be the best starting point.
Scalability & Maintenance: You shouldn't choose a technology & architecture that helps you prototype the project in the initial phase. You need technology that will support the growth of your company.
Our Stack
Based on the previous points, we decided to go with the following technology stack for NEWT:
API: Communication Layer
For our API, we have compared REST, GraphQL, and gRPC.
(*) simple representation
Selection Criteria:
- It should work for our apps & websites
- Schema-based request
- Easy to maintain & test
- Speed & smaller payloads
| Criteria | REST | GraphQL | gRPC |
|---|---|---|---|
| It should work for our apps & websites | ✅ | ✅ | ❌ |
| Schema-based request | ❌ | ✅ | ✅ |
| Easy to maintain & test | ⚠️ | ✅ | ✅ |
| Speed & Smaller payloads | ⚠️ | ✅ | ✅ |
Conclusion
GraphQL was the best option to cover all the uses cases we needed, gRPC is more performant for internal communication between our apps, but it's not supported completed for the web.
(*) In the future, we could have a combination between GraphQL & gRPC
Backend Programming Language
The decision about which programming language we would use for our backend was based mainly on 3 points.
① Current team knowledge
I have been working for the last 4+ years using TypeScript on the backend, allowing me to develop this project with confidence.
② GraphQL API & TypeScript works well together
There are a lot of mature libraries such as apollo-server & typegraphql that makes it a good development experience.
③ We are using React + TypeScript also on our frontend
Using a common language allows our developers to implement new functionalities in our API and our frontend (web, admin) simultaneously, increasing our productivity. Everyone in our team can read, review and share knowledge with each other.
Authentication
We have compared Firebase, Auth0, and Own solution for our Authentication.
Selection Criteria:
- Security
- Easy to implement
- Price
- Phone Verification
- Push Notification
- Integrations
| Criteria | Firebase | Auth0 | Own Solution |
|---|---|---|---|
| Security | ✅ | ✅ | ❌ |
| Easy to implement | ✅ | ✅ | ❌ |
| Price | ✅ Cheap | ⚠️ Expensive | ✅ |
| Phone Verification | ✅ | ✅ | ❌ |
| Push Notification | ✅ | ✅ | ❌ |
| Integrations | ✅ | ✅ | ⚠️ Manual |
Conclusion:
Writing our authentication system from scratch wasn't an option, and between Firebase vs. Auth0 considering our use case, the integrations we needed, and the price. Firebase was more than enough.
CI/CD
We host our code in GitHub and use GitHub Actions to run our workflows for continuous integrations and continuous deployment.
GitHub Actions has a lot of integrations that simplified our work: https://github.com/marketplace?type=actions
We are creating a testing environment for each one of our branches. It allows us to deploy to production after confidently completing all the QAs.
(*) simple representation
Infra & Database
About our infra, we had two candidates: Google Cloud and AWS.
We knew that instead of spending time deploying & maintaining our infra we wanted to focus on the product. So we decided to go with serverless solution.
The problem with serverless is the connections to the database, serverless functions can increase along with your traffic, but the database connections doesn't.
(*) Except for serverless databases that were not considered this time, we decided to go with a well-known database: MySQL.
Conclusion:
We decided to concentrate all the infra in one provider. We choose GCP for this.
GCP has Cloud Run, a fully managed serverless service for running HTTP-driven containers. It also allows you to connect directly to a Cloud SQL instance via a private network solving the common problem that serverless with databases has.
How we work as a team?
We are a remote-first company; all the tools we selected from the beginning allowed us to work with high productivity even remotely.
We have a culture to document everything we talk about and our decisions. It allows our teams to catch up quickly with what is happening around our product.
For the product team, we hold morning meetings to have a common space where everyone can share and ask the other team members.
Even if we are a remote-first company, we are trying to see each other at least once a week to increase the teamwork, and during that day, we hold meetings to think about how to improve our development process.
We are hiring!
There is a long way until we can achieve all we plan to do, and we have many unknowns. We need to keep moving and face each one of the problems as a team and find a solution for them.
If you are a talented developer who love to solve problems and discuss with other professionals the best ways to overcome them definitely you will love woking with us.
Let's talk and see how well we fit each other!
Feel free to contact us from the recruitment page:
令和トラベルのTech Blogです。 「あたらしい旅行を、デザインする。」をミッションに、海外旅行におけるあたらしい体験や、あたらしい社会価値の提供を目指すデジタルトラベルエージェンシーです。海外ツアー・ホテル予約アプリ「NEWT（ニュート）」を提供しています。（NEWT：newt.net/）
Discussion