I’m often asked during consulting engagements if anyone I work with has built their own API gateway. Yes, I do have a couple of clients that have built their own API gateway. One did so because they jumped into the API journey very early and the offerings at the time lacked the capabilities they needed. They continue to maintain their own API gateway, but the feature set is far behind those offered by many vendors – much like the situation that led them to build their own previously.
Another chose to build their own API gateway because no offerings existed that would operate in their preferred Windows-based server environment. I haven’t heard from them since as they still haven’t shipped their product – a full year later.
Let’s look at some considerations about building your own API gateway, before you embark on the journey.
Disclosure: Maybe you are wondering why an article about building your own API gateway is on an API gateway site. As you may have noticed, I produce evergreen content for sites like Tyk. While I partner with various API-related vendors, I strive to stay independent. None of them, including Tyk, pay me for my referrals. And I always offer at least two alternatives for any situation, to ensure my client finds the best fit for their need. The insights I am providing are from years of working with clients that have chosen to build and maintain their own API gateway, along with those that have chosen to use an open source or commercial solution.
It will take longer than you expect
Building your own API gateway often starts as a romantic notion. It shouldn’t take too long. It will do exactly what I need it to do – no more – and it will be much faster as a result. How hard could it be?
The truth is, building and maintaining a production-worthy API gateway isn’t trivial.
Below are just a few of the more popular requests one team has on their API gateway backlog:
- Adding basic HTTP/2 support
- Adding bi-directional HTTP/2 support for streaming
- OAuth 2.0 support (to complement their API key support)
- GraphQL support
- Custom routing rules based on a path URL fragment, customizable by each deployed service
Not to mention all of the deviations by non-standard clients and proxy servers that you will be debugging throughout the life of the API gateway.
Perhaps you are thinking that each of these items should be trivial if you find the right third-party library. You may be right. But that assumes the library was well-written, designed to address the exact needs you have, and will be maintained in the future against all forms of exploits, bugs, and language/framework major version releases.
And even if it does only take you a few months – is that time best spent by your organisation?
It won’t be as fast as you expect
“Make it work, Make it right, Make it fast” – Kent Beck
In software, there are commonly three phases of development: make it work, make it right, and make it fast. Often, developers are good at the first step – make it work. We experiment with code to see if something is possible, or perhaps to see what the result might look like before we proceed.
The effort required to go from making it work to making it right for production is vast. The edge cases are numerous and unforeseen. To make it fast while remaining production ready is yet another vast chasm to cross. Just ask Twitter.
In software, it is rare to experience the performance you expected without focused effort. And that effort is often more than you, your executives, or your budget are willing to invest. Allegro, an online shopping platform, documented their journey to building their own API gateway. They mentioned that they achieved their performance goals in 3 months, with an “average overhead of about 120 milliseconds (99th percentile) through the entire architecture”. But what happens if they need better performance?
They likely don’t have a dedicated development team to take it further – and they definitely don’t have a dedicated team the size of most API gateway vendors. Could they have used another solution to achieve the same results in less time? Probably. They made it fast enough for today. Will they be willing to re-invest in their custom solution when customers are pushing for them to resolve a performance problem? Perhaps. Do you want to do the same thing? I find that rarely the answer is yes by anyone but the developers wanting to build it.
Security is hard
Want to make it easier for an exploit to be found in your API? Build your own API gateway. Ask any company that has experienced a breach through their API – security is hard, even with the right components in place.
Applying proper security requires focused attention to detail at every aspect of your organisation. This includes the API gateway you build in-house. Unless you have a staff of security experts on hand, building a secure API gateway will take much longer than it takes to build your proof of concept version.
Building a test suite that exercises all aspects of your rate limiting, token expiration logic, and scope assertion rules will take much longer and more expertise than you may wish to invest. Skipping many of these security components because you don’t think you need them is a recipe for disaster.
Extending your custom gateway won’t be as easy as you think
You may think that your custom gateway will be easy to extend. Maybe it will, since you built it in-house. But what happens if the original developer leaves the company – will there be enough knowledge of how it works to support and extend it?
Next, time has to be allocated to build the new feature. This is where most teams struggle, as there are never enough developers available to implement the feature in a timely fashion. Imagine having a user story or epic in your backlog, blocked by a 1 month API gateway feature development. Good luck explaining that one to your managers, executives, and customers.
Your original vision will be wrong
Developers are an optimistic bunch. We often assume what we envision at the start is exactly what we need. Except rarely will that be the case. The original vision of your API gateway will deviate. Over time, it will look quite similar to the feature list of many existing API gateways. Be careful with the assumptions you have built into your vision and schedule to build out an API gateway.
Wrap-up
So, should you build your own API gateway? My answer begins with a no. I then review the exceptions identified to see if they are an exception to the rule. If so, then perhaps it should be considered. Even then, I recommend rolling out an existing solution into production first and then comparing it to what is eventually built. Often, the off-the-shelf choice isn’t as bad as you first assumed. And once it is in place, the time that would have been spent building the API gateway is better spent integrating an existing solution into their CI/CD process and returning to focus on delivering business value to customers.
If you’re interested in learning more about API success, be sure to check out our free whitepaper to get your API strategy started.
