Proxy, reverse proxy and API gateway

What are the differences between all of them? How do they all relate?

There is one overlapping concept that goes into all of those: connecting systems. The main function of all of these is to connect two or more systems that want to communicate. And the main difference lies in who is being connected and how this connection is being made.

To put it simply, the proxy will live between your system and the external world. Meaning that requests will come from the external world, arrive at your proxy and then be correctly directed into your system. And while at it, the proxy provides some cool functionality, like load balancing and caching.

A reverse proxy is similar to a proxy but operates in a different position within the architecture. While a proxy typically sits between the external world and your system to forward client requests, a reverse proxy sits in front of your backend services. This means it handles requests from either internal clients (e.g., a frontend service) or external users, forwarding them to the appropriate backend service. The distinction can become blurry because, when handling external client requests, a reverse proxy might seem like a regular proxy. However, the key difference lies in who it serves: a proxy represents the client, while a reverse proxy represents the server.

An API Gateway can do everything a proxy and a reverse proxy can do, and more. Depending on its configuration, it can act as a proxy, a reverse proxy, or both. Additionally, it offers extra functionality, such as handling authentication (e.g., validating tokens), transforming requests and responses, monitoring, and more.

Does this mean you should always choose API Gateways?

Not necessarily. All these features come with added complexity in configuration and maintenance. Choosing an API Gateway for the wrong use case can lead to unnecessary overhead and inefficiency.

Which one should I choose?

The correct answer is to say that it always depends on the problem you want to fix. But to avoid being overly generic, I would say to use the one that solves the current problem with the least amount of overhead. Meaning that the gateway should be your last option, and you should not try to create reasons to use it, like “oh, but in the future I might need this functionality”. This will very likely result in overengineering and wasted effort, two of the things I dislike the most.

For the large majority of systems, the simplest reverse proxy will be more than enough. It will protect your backend while also providing load balancing and caching if necessary. If it really doesn’t solve your problem, then start considering some proxy solution. An API Gateway should only show in the conversation the moment you have multiple microservices handling millions of requests with a lot of extra layers involved, like authentication and request transformation.