How to Build a Ridesharing App: The Back End
In the first article of this series, we discussed the components needed for the user-facing mobile app side of a ridesharing service. Let’s connect it with the back-end services and data the app needs to operate.
One of the toughest parts of integrating technologies into a business is figuring out how the features fit into the bigger picture.
In the first article of this series, we discussed the components needed for the user-facing mobile app side of a ridesharing service. We saw how this app can be built out of smaller applications described in various TomTom tutorials. Let’s connect it with the back-end services and data the app needs to operate.
In this article, we’ll walk you through the back-end architecture and some of the best practices for the APIs you’d use to power a ridesharing business.
RECAP OF THE RIDESHARING MOBILE APP USER-FLOW
Let’s briefly recap the mobile app we discussed in the previous article. The mobile experience for the ridesharing service targets two types of users — riders and drivers — and can be built into a single app or two different apps.
The Rider
The rider can request a ride, using a map display that shows their current location and the place where they will be picked up by the driver.
They can search for their destination with an address or place of interest. The app provides them with estimated distance, ride duration, and cost. Plus, they receive driver confirmation and proximity notifications. They are able to track the driver’s location and estimated time of arrival in real time.
After the ride, the app handles payment and prompts the rider for a review of the driver.
The Driver
The driver is able to sort ride requests and respond to them based on distance, destination, and drive time. They can also confirm that they dropped off the rider after a journey.
The app includes a route navigator to calculate and display the fastest way to reach the destination.
The driver can receive notifications of completed payment and review.
USER AND LOCATION DATA IN A RIDESHARING MOBILE APP
So, what data is needed to run this service? Let’s go through each part of the app experience and see what user and location information the back end must provide to the app, and how TomTom APIs enable you to build what you need.
Searchable Locations
One type of data that is critical to enabling a location-based service is up-to-date and accessible geographical information about places, roads, and events. Riders need to be able to search for their destinations and find pickup zones using this data.
Between Fuzzy Search and autocomplete, the Location Search API allows us to easily look up addresses and places of interest, while TomTom takes care of maintaining the database of over 100M points of interest in over 180 countries and territories.
Current Driver and Rider Locations and Geofencing
As each mobile device reports to the back end, we need to keep track of the device locations and match them up with each other based on proximity. If our ridesharing service had millions of users logged on simultaneously across the globe, it wouldn’t be feasible to send the locations of every device to every other device; that would be too much data. Our back end should allow some level of distance-based querying of riders and drivers.
This is where Geofencing is useful as it allows us to define a polygonal area of a map, and then use TomTom’s Notifications API to trigger a webhook for the various cases. A trigger might “fire,” for example, when a driver enters the rider’s geofenced area. It can also trigger a push notification to the rider that the driver will arrive soon.
Traffic and Map Routing
A mobility service must be able to route a trip and find the fastest way to get from point A to point B. By combining real-time Traffic Information from TomTom with the best routes and accurate ETA using the Routing API, our simple ridesharing service can provide the data that enables drivers to reach their goals.
Matrix routing is another capability of the Routing API that calculates all the possible routes and their ETAs through a single API call. Matrix routing calculations are limited to combinations of start and destination locations — waypoints are not considered — but back-end services for complex fleet applications can use this capability to automate the determination of the most efficient routes from a huge number of possible combinations.
For example, the matrix routing options can provide the route distance and ETA data needed to power a back-end service that determines which of a group of available drivers should be paired with each of a selection of rides based on getting all drivers to rides as quickly as possible. While those drivers are in transit, further asynchronous matrix routing operations could be calculating efficient future routes between drop-off locations and positioning for likely next pick ups.
Additional Data
Note that this ridesharing service will need to store and manage other non-location data, including user accounts, payments, profiles (such as names and photographs), ratings and reviews, and even vehicle information to help riders recognize drivers’ cars. These should be kept securely in a database for the app to retrieve.
BEST PRACTICES FOR USING THE TOMTOM API
Now that we know what data we need to build a simple ridesharing service and where TomTom’s APIs can serve as key pieces, let’s go over a couple of things to keep in mind when using these APIs.
Rate Limits and Transaction Costs
Remember that the number of times a TomTom API can be called per second is limited, and that API costs directly scale with the number of transactions. You may want to think twice before calculating a route for drivers after every mile!
API Key Security
Your API key is a password for accessing TomTom services and data, which means if a stranger gets their hands on it, they can use the APIs under your account and potentially run up your transaction costs.
The best way to keep the API key safe is to save it only on your back-end servers and ensure that only authorized people can access these servers. Don’t embed it in your mobile app, as it could be hacked.
Batch Routing and Location Searches
Remember that you can batch request routes and location searches in a single API request, and batch requests can be serviced asynchronously. This will help keep your service running smoothly and more efficiently.
PUTTING THE PIECES TOGETHER
In this article, we explored the design of the back-end data-providing side of a ridesharing service at a high level. We looked at how the various TomTom location APIs can provide key data for a mobility business. These back-end services can be built to work with TomTom APIs using any modern server technology, such as NodeJS or PHP, and database technology, such as Microsoft SQL Server or MongoDB.
The sample mobile application (which we dicussed in the first article in this series) would provide a front-end user interface for people to interact with the real-time data and notifications while connecting to the back-end Internet.
If you are ready to try TomTom APIs, click here to get started for free with an API key. For further details on using the TomTom SDK, we suggest that you take a look at our documentation, which explains how to use the API and integrate the SDK, as well as provides live examples of TomTom in action like the Taxi cars dispatcher tutorial.
Also, check out our blog for great articles and updates by our team. Feel free to reach out to us directly or connect with our community via our Developer Forum.
