When building a microservices-oriented system, the number of services grows with the number of features; the bigger the system, the more microservices you have.When you think about a user interface that has to interact with such a system, this can become tedious, complex, and inefficient (dev-wise and speed-wise). Gateways can help us achieve the following:
- Hide complexity by routing requests to the appropriate services.
- Hide complexity by aggregating responses and translating one external request into many internal ones.
- Hide complexity by exposing only the subset of features that a client needs.
- Translate a request into another protocol.
A gateway can also centralize different processes, such as logging and caching requests, authenticating and authorizing users and clients, enforcing request rate limits, and other similar policies.You can see gateways as façades, but instead of being a class in a program, it is a program of its own, shielding other programs. There are multiple variants of the Gateway pattern, and we explore many of them here.Regardless of the type of gateway you need, you can code it yourself or leverage existing tools to speed up the development process.
Beware that there is a strong chance that your homemade gateway version 1.0 has more flaws than a proven solution. This tip is not only applicable to gateways but to most complex systems. That being said, sometimes, no proven solution does exactly what we want, and we have to code it ourselves, which is where the real fun begins!
An open-source project that could help you out is Ocelot (https://adpg.link/UwiY). It is an API gateway written in C# that supports many things that we expect from a gateway. You can route requests using configuration or write custom code to create advanced routing rules. Since it is open source, you can contribute to it, fork it, and explore the source code if necessary.If you want a managed offering with a long list of features, you can explore Azure API Management (https://adpg.link/8CEX). It supports security, load-balancing, routing, and more. It also offers a service catalog where teams can consult and manage the APIs with internal teams, partners, and customers.We can see a gateway as a reverse proxy that offers advanced functionalities. A Gateway fetches the information clients request, which can come from one or more resources, possibly from one or more servers. A reverse proxy usually routes a request to only one server. A reverse proxy often serves as a load balancer. Microsoft released a reverse proxy named YARP, written in C# and open-source (https://adpg.link/YARP). Microsoft built it for their internal teams. YARP is now part of Azure App Service (https://adpg.link/7eu4). If YARP does what you need, it seems like a stable enough product to invest in that will evolve and be maintained over time. A significant advantage of such a service is the ability to deploy it with your application, optionally as a container, allowing us to use it locally during development.Now, let’s explore a few types of gateways.
