Third-Party APIs and Integration

Nardiéna Althafia Pratama
HappyFresh Fleet Tracker
2 min readNov 22, 2019

There are lots of third-party APIs that can be integrated into a project for different kinds of purposes. One of the purposes it can offer is to help create mapping components like in our project.

In our project, FleetTracker, the Google Maps API is one of the most important components in the front-end side. In this article, I will be talking about the decision of using third-party APIs in our project and how it is integrated within it.

The Project Requirements

In FleetTracker, one of the main requirements is to display the estimated and actual route of the driver on the map. The estimated route is supposed to be the most efficient one that the driver could take, taking into account the traffic conditions, and is shown on the map in HappyFresh’s app.

Google Maps, in comparison with other Geographic Information System APIs, is surely rather expensive. However, the traffic coverage that is given by this API is much more accurate, and so our team decided to use it in FleetTracker.

Market share between mapping APIs (http://www.datanyze.com) — Source: M. Naufal’s GMaps Article

First Try

Initially, in the front-end development, our group decided to choose MapBox as our mapping API. This is mainly due to the fact that MapBox is much more affordable than Google Maps and has a quite feature-rich library, as well.

However, its lack of accurate traffic coverage in Jakarta, which is needed in our project, led us to switch to Google Maps — price no longer an issue as it turned out that HappyFresh already had a subscription to GoogleMaps API and so they were the ones who deal with the expenses.

Source: https://sspectra.net/get-google-maps-api-keys/

Documentation

APIs are implemented into a project in order to help with the usability of a service. However, sometimes the documentation provided by the API could have poor readability, which at first may be of little effect to the developer, but as the development continues, it would potentially become such a hassle trying to decipher the explanations in the documentation.

Source: M. Naufal

This is an example of a poorly-structured documentation. Our main front-end developer has experienced dealing with this sort of API documentation, and it surely has led to struggles in the development.

So that is all for this article! Hopefully, it was useful. Thanks for reading!

--

--