The Algolia Places API is coming to an end on May 31st, 2022. If you are a developer who uses this API in your projects, you may have mixed feelings about this. I say “mixed” because you probably alerted other parts of the company when the original announcement went out in November 2020. But when the sunset is 18 months down the road, other priorities take the lead. Now you are looking at the Q2 goals in Jira and read, “Migrate from Algolia Places API.”
Well, if it isn’t the consequences of others biting ME in the butt…
Hopefully, this article will give you guidance on what is out there as a replacement for Algolia Places and what it will cost going forward. We've also created some example code so that you can get a sense of how heavy a lift it will be to do the changeover.
Google Places
One of the obvious choices is using the Google Places Autocomplete API. Google offers an endpoint “autocomplete” that will allow you to put in free form text. If you are using this on the frontend, you can reference the “AutocompleteService” and it will turn any text input field into a combobox.
The pricing structure is a bit convoluted – calls returning certain attributes are priced differently than others. For example, the Basic Data set of attributes (which would include things like the name, address, photo, etc.) are priced differently than the Contact Data set of attributes (website, phone number, etc). Now, if you are wondering to yourself, why is the price determined by the returning attributes rather than the amount of calls you make, then you are asking the right question. Like AngularJS, sometimes Google just likes making stuff overly complicated.
If your app needs to display detailed metadata information about a location or address then this is the way to go.
Mapbox
This company has been around a long time and has an extensive suite of mapping tools. The API that most closely matches up to Algolia Places is their Geocoding API. This API allows you to forward geocode and reverse geocode. The API is broken down into two different endpoints – mapbox.places and mapbox.places-permanent. The mapbox.places API needs to be triggered by a user action and the results can only be shown on a Mapbox map; not doing so breaks Mapbox’s terms of service. The mapbox.places-permanent endpoint is good for batch processing but Mapbox suggests reaching out to their sales department before using this. This endpoint also lacks a lot of POI (point of interest) data that would otherwise be included in the mapbox.places endpoint.
If your app needs to search through POI metadata and display it on a map, then this is the service for you.
Geocode Earth
Geocode Earth is another suggested service that Alogia recommends as a replacement. This service offers an endpoint called “autocomplete” that can be used to forward-geocode user input. There is also a structured forward geocode endpoint called “search/structured” that is good for processing addresses that are in CSVs or database results. Both endpoints also have parameters that allow you to search in a radius around a single coordinate or a custom bounding box.
The good thing about this service is that they offer a web components piece that can be placed on your website—one of the first times I have seen a service use this browser-native API in the wild. If your project needs extra information about POI information in the response, i.e., type of business or hours of operation, then this won’t be for you.
If your app heavily relies on processing addresses coming from a datastore or you are dealing with structured address data, then this is the service for you.
Geoapify
This service offers a suite of geography APIs that can search for POI data, reverse geocoding, and batch geocoding. The one that we are going to talk about is the geocoding API. This API allows you to get a properly formatted address along with latitude and longitude coordinates. This service has a “confidence score” that ranks how accurately the returned address matches the inputted address. The downside is that they have a weird payment plan structure. Essentially, you are charged by the number of API calls: 1 API call equals 1 credit. Much like NBA2K VC, you buy packs of credits per month.
If you don’t mind the pricing scheme, and your app doesn’t have a hard requirement to show addresses on a map, then this service will suffice.
Lob
You can use the address verification API that Lob offers to do forward geocoding. Lob offers both US and International APIs. Like Geocode Earth, Lob isn’t going to return detailed POI information, but there is no need to trigger the API request from a user interaction like Mapbox, and the pricing model is more straightforward than Geoapify. The added bonus that forward geocoding allows is a “deliverablity” flag. This lets you know that not only is the input a valid address, but also a location where someone gets mail. If your application or project absolutely needs to verify that something sent via USPS can be delivered to the location and reach its intended recipient, Lob will be your best option.
If your app deals with shipping (either mail or goods), then this is the better choice. The deliverability score that Lob offers allows you to know whether the input address can actually receive items.
Conclusion
Hopefully, swapping to a different provider will be easy. If not, this may be a good time to refactor that particular piece of your system according to the clean architecture principles. If you see other parts of your system that rely heavily on 3rd-party services, now may also be a good time to refactor those portions of the system as well. You never know what forces may be at play that will force another provider to drop functionality or service all together.
Top comments (0)