At bearer.sh, I've been interviewing dozens of developers and experts to understand how they build and manage their API integrations.
I've compiled those findings into a series of blog posts, here is the first part below, that is all about API clients.
First, why should I care?
Because as the number of integrations you build tends to grow, consuming all those third-party APIs at scale becomes a real technical challenge.
Integrating one or two APIs is not always that complicated, but when it comes to build dozens of integrations, each providing key business-critical components to your application, that’s when things get more complex (and interesting!). From there on in, you realize that every API is a single point of failure that needs to be managed accordingly; dealing with technical debt and security is going to be paramount.
Using API clients?
How difficult can it be to consume an API, after all? It’s not like it’s something new, right? Sadly, it is difficult, and it's at that precise moment we usually all make a critical decision:
Hey, I've found an API client for xyz API, let's use it it's going to go faster
But, what we've found out is that using a dedicated API client is the best way to build technical and security debt over time. When you think about it, most of the time, those API clients are just nice wrappers over REST calls. Ideally, they are provided and maintained by the API vendor, but it is more often not the case.
Imagine yourself consuming dozens of APIs, not an unusual feat, it means relying on dozens of dependencies,+ their own in turn. This will translate into numerous updates and security patches over time. Add to that the fact that, every API call will look different in your codebase; you quickly realize this may not be have been the ideal decision!
By the way, would you query your DB using a different client for every table? Different methods? It's not just because data comes from an API, that you should suddenly forget all your best practices.
From that single unspoken decision, the impact over time is going to be dramatic.
Great, what's the solution?
First, the keep it simple stupid (KISS) approach would simply tell us to query the API using a regular HTTP client (axios, httparty etc.). Yes, It is going to be more verbose, but is that a bad thing after all?
The ideal solution that we've seen is to build a dedicated service, responsible for querying all your third-party APIs. This way, every integration will rely on the same pattern, structure, and dependencies; you will be able to improve this service over time, and by design improving all your integration's codebase. You can think of it as a micro-service or a module for example, depending of your preferred architectural choice obviously.
And finally, you can also give a try to our universal API client if you don't want to reinvent the wheel 😅.
I'd love to know how you build and manage your integrations, tell me more in the comment section below!
Top comments (0)