14-day free trial
Create a full-featured search experience in no time.
Sorry, there is no results for this query
So you want to build your web application using third party APIs. Given so many options, how do you choose?
One of the beautiful things about Jamstack is that, along with boosting performance and scalability, it allows you to build your web application using any number of third party APIs. The result is that you can plug in best-in-class products for each individual job, and make use of continuous innovation in every specialized area; it’s unbundling in a way.
Think about implementing Algolia instead of building a custom full-text search module, or implementing Contentful instead of grappling with your own CMS hosted on servers you’ll have to maintain, or using Netlify’s seamless development workflow instead of compiling source code yourself and uploading it to a web server via FTP. Moreover, this pattern allows you to switch out individual services easily, whenever you find a better solution for any part of the stack.
With choice, of course, comes responsibility: how should you choose what solutions to use given so many options?
In this post, we’d like to share 5 criteria to consider when choosing an API for a project.
You’re buying a service that needs to fit neatly into your architecture, but also be balanced with the needs of the non-technical stakeholders, as it’s something they will manage. Therefore you need the best of both worlds: a fantastic API with equally fantastic documentation, along with an accessible and feature complete business dashboard, all the while keeping flexibility and control in balance for both stakeholder groups.
Now, when building a software product, it’s all about tradeoffs. With less mature products, you’ll likely find more of an emphasis on either the developer or business focus. Therefore, the first requirement is to look for a reasonably mature provider who has built competency in both areas, and try to minimize this trade off where possible.
When it comes to the API itself, look for signs that the API is not seen as a service, but rather a solution:
You’ll want to look at any complexity added to the data flow and deployment process when adding an API provider. For example, when using a headless CMS, you will need to trigger redeploys of your site when your content gets updated. In this case you’ll want to look for an integration guide on how to set up the webhooks. In the example of a search API like Algolia, you’ll need to pipe your content to the search API when it gets created or changed, and remove it when it gets deleted. Moreover, your content can come from many different sources like articles, products, and more.
Luckily, many providers for the Jamstack make this easy to figure out. Be sure to check that they have tooling which integrates to other Jamstack technologies you are considering. If there is a direct integration between tools, that is even better. For example, if you are using Algolia with Netlify, you can make use of Algolia’s Netlify plugin to simplify the aforementioned process.
When choosing an API-first provider, you’ll need to consider your UI. APIs are built to give you freedom on the front end, and they try not to be opinionated about the interface in which they will be embedded. Traditionally, this has meant that you have to build all of the UI.
However, as services have matured, many providers now offer UI components for developers to use. These components often have a best practice UI implemented in the interface while using the service’s API client under the hood.
If you are using a provider with UI “components”, or “widgets”, there are trade offs to consider. A headless approach provides freedom and flexibility in design and user experience. Using a provider’s widgets gives a faster path to building a front end, though you usually lose some of that freedom of design customization. How should you validate such tools? Look for smart defaults, and the ability to override the UI itself, without losing the logic built into the components. This way, you can start with defaults, and quickly evolve, without having to rebuild everything as soon as you stray too far from the provider’s standard patterns. To use Algolia as an example: developers have the ability to extend widgets to customize the UI and keep the functionality provided by the widgets, or even create custom widgets by building directly on top of the underlying library.
Since you may be managing multiple providers in your application — maybe one for each use case — you will want to make your life as easy as possible from an admin perspective. Here you’ll want to consider a few elements for each service:
It’s an exciting time to be a developer in Jamstack. You have the freedom to choose APIs that best fit the problem you’re solving or the product you’re building. In the coming months and years, we can expect more services to be introduced. We hope this guide will help you choose the right API for your next project.
About the authors
Matt works on solutions engineering at Algolia, having previously been with Twilio, a communications API, and Moltin, a (now acquired) ecommerce API.
Sarfaraz Rydhan is director of partner ecosystem at Netlify. Sarfaraz works with technology and business leaders, helping companies reach customers better by using JAMstack web architecture. A seasoned ex-software engineer, Sarfaraz uses his technical and operational expertise to help these companies serve new markets and to approach technology decisions with clear business outcomes in mind.