API Gateway is a great “middle-end” to the backend and frontend. In this article we’ll go over what exactly is an API Gateway, how it works, what are the benefits and where it fits in the building of modern applications.
What is an API Gateway
It is a service that sits between a client, and a collection of backend services hence dubbed “the middle-end”. Main use case for an API Gateway is to aggregate all the necessary services to fulfil a contract. However, API Gateway is also – at the core of it – a reverse proxy, so it provides increased scalability, performance, resilience and security. More on that later.
Case study
In order to explain what API Gateway actually does, I will use an example application. Below is “PAWnshop - an app for puppy lovers”.
This is an old-school monolith application with a single endpoint to get all the necessary data. We have puppy info, reviews, adoption and for users who cannot adopt they can take a puppy for a day to play with and keep company.
This is a microservices app. We separated each functionality into a separate service, so we have a puppy info service, adoption service, reviews service and play service.
Now, we need go to our frontend developer and explain to him why that one endpoint he has for getting all the needed data to display the puppy page is not good anymore. Then give him four more endpoints, one for each service. Here’s the kicker though, everytime a user wants to schedule puppy play time we have to ensure data isn’t stale. Play service doesn’t have access to puppy info, so now we have to first send a request for fresh puppy info, get it back, check if puppy is free that day, send a request to play service and get back a response to tell the user he’s scheduled a puppy appointment. Way more work than it should be.
Enter API Gateway. We can keep the exact same API for the frontend service as if backend was still a monolith while at the same time implement microservices architecture. API Gateway will be responsible for accepting the client request and calling all the services needed to return the necessary data all at once. This greatly improves both the user and developer experience.
Benefits
We’ve covered one benefit of API Gateway already – user and developer experience – but there’s many more
Improved client performance
Left unmentioned alongside improved user experience was improved client performance. A single call to the api gateway that then handles all other requests to all necessary microservices greatly improves the client performance than if we had to make x amount of separate calls.
Protocol Translation
Without the API Gateway, we need the same protocol to go from the client to the microservice(s). Most often it’s https. With API Gateway we can change the protocol between the gateway and the microservices to http while at the same time keep the https protocol between the gateway and the client. This technique is also called SSL Termination. Thanks to this technique we can rely on just a single SSL handshake between the client and gateway. This will also slightly increase performance as we won’t have to send encrypted requests to each and every microservice.
You can also use Protocol Translation to support completely different protocols e.g., AMQP, which might give you larger reach with your site.
Security
Using API Gateway improves security by preventing malicious Denial of Service(DoS) attacks. We can also add authentication and authorization for an additional layer of security e.g., API Keys. It also provides us with great logs and metrics to monitor what exactly is happening with our API Gateway.
Common functionality offload
Offloading common functionalities that had to be included in each microservice by putting that logic inside the API Gateway e.g., encryption/decryption
Backend for frontend application
Each client type can have their own api gateway e.g., gateway for web, gateway for native app, gateway for desktop app, gateway for IoT devices, gateway for third party integration etc.
Drawbacks
Everything is about trade-offs and API Gateway isn’t any different.
Speed
Using API Gateway will naturally be a slower solution as it introduces an intermediate step between client and server so there will always be two “hops” for each request. Rather than talking directly to the server.
Redundancy
Adding redundancy will affect the speed even further. We probably wouldn’t want to rely on a single API Gateway to handle all our traffic ‘cause once it’s down it’s all down. So we’d probably need more than one and then we would have to put a load balancer in front of them to direct traffic. This adds another level of complexity and slows everything down by adding yet another “hop”.
Summary
In this article we have learned that an API Gateway is a reverse proxy that sits between the client and the server. Its main responsibility is to aggregate all necessary services in order to fulfil a contract. We also went through a short case study, where we could see how API Gateway improves both user and developer experience when building an application with a microservice architecture. When building software it is always important to know the trade-offs so we’ve gone through the benefits like improved client performance or protocol translation and compared it with the drawbacks. Knowing that API Gateway will slow us down is important in case we’re building an application where every millisecond matters.