- We found that the bottle neck to be multiple rates call, quick add api call, few queries, database views
- The Itinerary page will have a city level loader that preloads the required travels/activities/guides data for dropdowns
- While a city is loading, the following things are inaccessbile
- Adding a new city
- The controls for a city will be enabled once the city loading is complete(Edit/Add/Delete services)
- All the controls will be enabled once all the city load is complete(Add a new city)
- The max loading time for all the cities to be kept under 8 secs.
- The drop-downs for Add Travel, Add Activities, Add Guide, Add Hotel will be instantaneous after this.
- The default price shown will be removed from All services except hotels.
- Rates will have an endpoint that returns only the default price.
- Poovannan to check on if that api can be further optimised
- Quick adds will be moved to a separate API
- Frontend will take care of merging quick add results to the normal services results
- All the services / except quick-add will be moved to redis.
- There is some scope to optimize the SQL Queries.
- Since the quick add services will be moved to a new api, we can remove the database views completely and query the table directly.
- We're actually split on how do we do rates Single rates api call vs Multiple rates API Call.
If a proposal has 15 cities, 1 api call for initial load, 1 x 15 calls for getting travels, guides and activities, 1 x 15 for getting hotel with default prices, 1 call for quick add. All of these parallel