Goibibo Doubles Down on Contactless Check-in Services: Here’s everything you need to know

How often have you longed to skip the long check-in process at the hotel reception and dive straight into your room? How many times have you dreamt of checking-in as soon as you reach your destination or even while you are on your way to the hotel? The answer would sure be ‘many a times’.

Thanks to the pandemic, the travel industry has successfully managed to digitise high touch-points at the hotel and to begin with - check-ins that usually involved spending minutes at the front desk producing and verifying ID proofs, signing check-in documents etc. has now moved ‘Online’. Introducing ‘Contactless or paperless check-ins’ that allows you to cut down your waiting time at the concierge and head straight to your room to relax or at the beach café for a refreshing drink!

At goibibo, our tech experts are working around the clock to enhance the experience for travellers. They are working to ensure that the overall hotel stay experience gets elevated while providing safe and contactless way for people to be out and about in the new normal.

But ‘digital check-ins’ on the goibibo platform did not happen in 2020 when the world was hit by one of the biggest challenges, instead goibibo had taken its first step towards paperless priority check-in through QR codes and pre-validation of ID proofs back in early 2018 – putting an end to last minute ID validations, room allocation process and the long wait at the hotel reception. Two years hence, and with an enhanced and tech-rich, document-less check-in process that helps optimise time for the traveller and improves efficiency at the hotelier’s end, goibibo, today, offers Contactless check-ins at 2500+ hotels (and counting) across the country.

So, here’s how goibibo’s bookers and non-bookers can make the most of the ‘Contactless check-in’ offering available on the app.

goibibo bookers -

Step 1: Bookers can now submit ID proofs and other validation documents online post making the payment or via My Trips –upcoming trip section on the app.

Step 2: Once the documents are submitted the hotelier verifies and approves or rejects the documents.

Step 3: If approved, upon reaching the hotel, the customer will be able to check-in by sharing her/his contact number or booking ID at the front desk –avoiding the tedious exercise of producing and verifying ID proofs while waiting anxiously to check-in into the room.

For non-bookers -

These are the travellers who make impromptu plans and directly reach the hotel (we have all been there, done that!) -

Step 1: First step, do not worry and breathe! goibibo has it all sorted 😊.

Step 2: Open goibibo’s app and click on the ‘Scan & Go Contactless’ icon.

Step 3: Travellers can upload soft copies of the documents on the app after scanning the QR code and wait for the hotelier to approve the documents.

Step 4: Once approved, the traveller can proceed to her/his room.

With its core objective to bring down the entire check-in process to just a few taps on the app, the ‘Contactless check-in’ feature promises to offer additional benefits to both, the hotelier and the traveller. Hoteliers can now generate their own unique QR code for collecting guest documents and payments, sharing Wi-Fi details and food menu, and most importantly, allowing non-goibibo bookers to make an easy and hassle-free Contactless check-in through the app.

At the backend, the micro service architecture (diagram below) configures information gathering and sharing framework, payment collection and notification settings securely for the hotelier — moving majority of the manual work done by the front-desk staff, seamlessly online.

In parallel, the traveller benefits from a seamless travel booking experience as she/he can now search, book, pay, check-in and explore F&B options at the hotel on a single platform.

In the wake of the pandemic, the hospitality sector is turning towards embracing new safety measures. And, Contactless check-ins is one such step towards prioritising safety of travellers — a concept that is here to stay for its ease and simplicity!

Shout out to Rahul Goyal, Naveen Setia, Rahul Jethwa, Amit Kumar, Harsh Jasoliya, Saravanan S, Madhur Garg, Sharat Hegde & Tanisha Sabherwal and the entire team at goibibo behind ‘Contactless check-ins’ for our partners and customers.

Goibibo Doubles Down on Contactless Check-in Services: Here’s everything you need to know was originally published in Backstage on Medium, where people are continuing the conversation by highlighting and responding to this story.

Goflow — A graph based solution to building middleware

At InGoMMT we cater to both mobile and web clients. There were cases where we realised that mobile doesn’t need the same amount of data as required by the web, from the same API. This led us to develop a microservice which was deployed as a GraphQL middleware between clients(mobile/web) and backend services/database, we call this microservice Enigma (a backend for frontend). More about GraphQL here.

Problem Description

Serving a typical request from a client(s) would require enigma to perform one or more of the following operations:

• Call other back-end service(s), let’s call this OperationAPI
• Perform database calls to SQL/Redis, let’s call this OperationDB
• Perform some business logic on the returned data from OperationAPI or OperationDB, let’s call this OperationBL

From now on we will refer to OperationAPI, OperationDB and OperationBL as Operation in general, unless specifically mentioning the operation.

As the number of features started increasing, we started observing the following:

• [Problem-I] data returned from Operation(s) were needed as input to other Operation(s) i.e. dependencies among Operation(s). But handling this was becoming more difficult as the number of Operation(s) and their dependencies increased.
• [Problem-II] even though OperationAPI and OperationDB were being performed concurrently we didn’t achieve the most optimal concurrency.

Most optimal concurrency?

Operation(s) which were independent of each other can be executed concurrently, to solve this we had a simple Executor which used to take Operation(s) as input, execute each Operation in a separate go routine, wait for all the routines to finish and return the result in a slice.

The above solution seems to work but if we look closely, we can see that this is sub-optimal solution because time taken to finish set of N-Operations will be:

Hence Operation(s) with smaller runtime will have to wait for all the larger runtime Operation(s) before moving on to their dependencies. If we can execute each operation completely independent of each other while at the same time honouring the dependencies among each operation, we will achieve the most optimal concurrency.

Solution — Graphs

We need to look at the problem in a different way, if we notice, each Operation along with their dependencies form a dependency graph with Operation(s) being nodes of the graph and edges representing the dependency.

So, doesn’t it solve our problem if we construct a graph and run its node in the order defined by its edges. Wait, isn’t that called topological sort?

Can we extend this to OperationBL? Yes, we can, why not make business logic a graph node too? So here the complete solution:

Convert OperationAPI, OperationDB and OperationBL into graph node and add dependency among them via edges. Now give the graph to a graph controller which picks nodes from the graph in topological order and feeds it to executors which run a node in a separate go routine.

Implementation

In-depth description of implementation is a separate topic in itself but an overview can be understood by observing the interface(s). The comments above each interface will give a good overview about the system.

It is worth mentioning about data transfer between graph nodes. Data transfer is user defined, this is because Goflow operates on the OperableDataStore interface(refer above). Users can implement the PeekAll() method which provides the logic to retrieve all the data present in OutboundDataStore of a graph node.

There are three more entities in the system:

1. Manager — manages configuration of the system
2. Controller — controls each graph, breaks them down into nodes
3. Executor — executes each node

Details of these are beyond the scope of this blog but the image gives a good overview.

Performance

Goflow is already in production and many features are already converted to graphs. Scale analysis of the complete system was also done, for this a dummy graph was made whose execution time was around 500 msec mimicking a typical request resolution logic.

Multiple instances of this graph were fed simultaneously to the graph controller and average/total time to execute all the graphs were calculated.

What did we achieve?

1. This solution (named Goflow) is available for any other team to use and is a separate repository.
2. Using concurrency in an optimal way, thus reducing latency.
3. Data management between Operation(s) became easier.
4. Forcing modular ways of development on developers, leading to clean code.
5. Modular coding also leads to code reuse, thus saving development time.
6. Abstracted the solution as much as possible, which helped us in easily decoupling Goflow from Enigma, this is because initial development of this idea was done in Enigma.

What’s Next?

1. Details of implementation, actual execution of graph via graph controllers and executors.
2. Advanced topics on golang channels like bounded parallelism/concurrency.
3. Trie based URL manager, since we are a middleware, we deal with a lot of API endpoints, this is an interesting solution unrelated to goflow but was developed along with it.

Goflow — A graph based solution to building microservice was originally published in Backstage on Medium, where people are continuing the conversation by highlighting and responding to this story.

React — A Migration Journey at Scale

Let me tell you about a journey of one of the biggest travel platform of India. A journey that helps ~100k Hotel Partners get the best out of selling on two of the biggest OTA brands of India — Goibibo & MakeMyTrip. Journey that began with the sole intention of providing the best experience possible while also keeping upto date with the latest advancements in technology. This is the journey of one of the best Hotel B2B portal of India — InGo-MMT.

Oct 2018

This journey started all the way back, about 4 years back, when we slayed the monolith which was holding both Frontend & Backend code. I don’t think we need to go over the reasons over why we chose ReactJS. It’s been extensively covered already like here. We created a new microservice, which was built on a custom setup powered by Create-React-App which was a golden standard at that time. We had to build custom tooling so that we were able to keep a hybrid app running both React code as well as pre-existing jQuery code running hand-in-hand, bringing the same goodness that CRA provides to our legacy code as well.

With this initial start, we created our new microservice and we began our journey of progressively converting the whole webapp into React. And we did this progressively since as much as the developer inside us wants to sit & migrate all at one go, we also wanted to keep providing our Hotel Partners better experiences, newer ways of engaging with our platform and sell their Hotel experiences better.

Our custom setup included things that were unheard of before, like:

• Keeping & using multiple HTML files loaded into a SPA
• Writing conditional logic inside index.html
• Keeping legacy code as it is by keeping them out of src folder and setting up building & versioning legacy code

You can read all about the initial start here: https://tech.goibibo.com/django-unchained-literally-fa90697dc37e. This could also help you in kickstarting migration of your legacy applications as well. Thank me later :)

2018–2022

This has been the most exciting tech journey of our lives. We have seen the complete ins and outs of what it takes to go from a basic MVP to becoming one of the best applications in the travel B2B space. Here are some of the key highlights:

• We went from React in jQuery app → jQuery in React app → React app
• We went from an app with about 20+ modules & features → an app with 100+ modules & features
• We went from building in-house component library to using Material-UI and StorybookJS for building our component library
• We had tried out multiple libraries to finally settle on react-hook-form for forms, react-day-picker for calendars, moment for Date manipulations (oh btw, it tree-shakes well 🧐), recharts for charts and react-table for tables.
• We have used different approaches in building the UI — Config Driven UI, BE template driven UI, Windowing, Lazy Loading etc.
• We religiously keep our dependancies upto date every quarter. And for instance, we put react-hooks to production on the day the stable version was released.
• Our CSS approach went from plain CSS → SASS → Styled components → CSS-in-JS (via MUI) → Tailwind CSS

In the same timeframe, our team grew from 1 frontend engineer (me 🧑‍💻) to a team of 12 FE Engineers 👭🧑‍🤝‍🧑, 4 QA Engineers 🕵️️ & 4 designers 🧑‍🎨.

The best part about this journey is that we have created a culture of collaboration, exploring different approaches, experimenting with ideas, trying out different libraries, figuring out the best way to do things in a democratized manner which takes opinions & feedbacks from everyone involved. We have evolved our tech stack & coding standards and scaled that to get the best out of our big team of developers. And all of this is done with a very clear focus on what’s best for our customers — the Hotel Partners.

You can also read a bit about the initial journey, challenges we faced & how we overcame here: https://tech.goibibo.com/modernising-legacy-web-app-51ba952e7630.

The Destination

After almost 4 years of development, in which new functionality & enhancements for our Hotel Partners always took the first priority, and the tech migration progressed at a snail pace, we have completely migrated to a 100% ReactJS webapp.

What started with 250 files, 80K lines of code repo has now grown to ~2000 files, >270K lines of code.

The best part is hearing the same from our Hotel Partners on how their experience is.

Using the InGoMMT after a very long time, I was surprised by the completely new and fresh look and the ease of use. It is now comparable or even better in some cases compared to the other platforms. Keep up the good work.

Let’s talk Performance

Obviously when working on building such a humongous webapp and continuously shipping new features, the primary focus is not on Performance. But we solve for it in 3 important ways —

• The architechtural choices like code splitting at route level, having a proper pre-defined Data flow, always using pre-defined components and using common utils & hooks which are already optimized.
• Rigorous testing & very detailed code-review process for every new change ensures that we not just deliver the functionality but keep it performant.
• Periodic review on the performance by monitoring bundle sizes, checking Lighthouse and observing trends in Analytics. And fixing issues.

The final cleanup

To complete the migration process and doing the final cleanup of all legacy code, we also took up the another round of optimization along with it. Our legacy code powered all the analytics logging across entire codebase. That was one of the last big dependancy of the old code. Here are the things we did in the final cleanup & optimization.

• Remove all of legacy code, legacy libraries like jQuery, BackboneJS, underscore and all the custom tooling we had setup for legacy code.
• Move the core analytics logging utility inside src and update references across 1000+ files using custom codemod script via jscodeshift 😎
• Restructure all the assets (icons, illustrations) and reused code into properly segregated shared_logic folder so that common chunk doesn’t bloat up. (saved about 250Kb gzipped size from common chunk 🔥)
• Just running npm dedupe saved about 50Kb gzipped size overall 🤯. For those who don’t know, it removes multiple versions of same library dependancies. Best done along with updating all libs to latest version.
• Also added a bunch of useful scripts — script to make sure assets added to project are properly utilized, added script for logging consolidated size of website assets along with custom performance budgets, script to compare two lighthouse reports (exported as JSON).
• Moving to Vite JS 3.0 which would require another blog post to go into details. This saved another 160Kb gzipped size across all JS chunks 🥳.

The impact

As you can see from our script output here:

• The overall gzipped size of our application went fown from 1500Kb to 950Kb. An amazing 36.7% reduction. 🥳🥳
• Our main JS chunk went down from 756Kb to 420Kb. A sick 44.4% reduction. 🤓 While our unused JS (on load) reduced by 50%.
• Script evaluation time saw a good 31.5% reduction & Script parsing saw a jaw-dropping 90% reduction.

This is a comparison of best of 10 lighthouse reports of both before-optimization and after-optimization run in incognito mode.

A New Journey begins

After completing this journey of migration, our work doesn’t end here. We will continue to strive to bring useful features, smooth experience for our hotel partners. Here are some of the things that excites us looking ahead:

• Setting up Real-User Monitoring — Currently analytics data gives just an indicative measurement & trends on how the performance is. We want to be correctly measuring the performance for a SPA.
• Completing our migration to Tailwind CSS from existing SASS
• Completing our tech debts in few of the early modules to bring it to the latest established coding standards.
• NextJS is also in the plan with an eye out for the stable release of React Server Component :)

If this journey has taught you something, don’t hesitate to show your appreciation on the like button so that we can grow together in this journey and encourage us to share more learnings like this. 🧑‍💻🧑‍💻

React — A Migration Journey at Scale was originally published in Backstage on Medium, where people are continuing the conversation by highlighting and responding to this story.