A gateway is a façade that shields or simplifies access to one or more other services. In this section, we explored the following:
- Routing: This forwards a request from point A to point B (a reverse proxy).
- Aggregation: This combines the result of multiple sub-requests into a single response.
- Backend for Frontend: This is used in a one-to-one relationship with a frontend.
We can use any microservices pattern, including gateways, and like any other pattern, we can mix and match them. Just consider the advantages, but also the drawbacks, that they bring to the table. If you can live with them, you’ve got your solution.Gateways often become the single point of failure of the system, so that is a point to consider. On the other hand, a gateway can have multiple instances running simultaneously behind a load balancer. Moreover, we must also consider the delay added by calling a service that calls another service since that slows down the response time.All in all, a gateway is a great tool to simplify consuming microservices. They also allow hiding the microservices topology behind them, possibly even isolated in a private network. They can also handle cross-cutting concerns such as security.
It is imperative to use gateways as a requests passthrough and avoid coding business logic into them; gateways are just reverse proxies. Think single responsibility principle: a gateway is a façade in front of your microservices cluster. Of course, you can unload specific tasks into your gateways like authorization, resiliency (retry policies, for example), and similar cross-cutting concerns, but the business logic must remain in the backend microservices.
The BFF’s role is to simplify the UI, so moving logic from the UI to the BFF is encouraged.
In most cases, I recommend against rolling out your hand-crafted gateway and suggest leveraging existing offerings instead. There are many open-source and cloud gateways that you can use in your application. Using existing components leaves you more time to implement the business rules that solve the issues your program is trying to tackle.Of course, cloud-based offerings exist, like Azure Application Gateway and Amazon API Gateway. Both are extendable with cloud offerings like load balancers and web application firewalls (WAF). For example, Azure Application Gateway also supports autoscaling, zone redundancy, and can serve as Azure Kubernetes Service (AKS) Ingress Controller (in a nutshell, it controls the traffic to your microservices cluster).If you want more control over your gateways or to deploy them with your application, you can leverage one existing options, like Ocelot, YARP, or Envoy.Ocelot is an open source production-ready API Gateway programmed in .NET. Ocelot supports routing, request aggregation, load-balancing, authentication, authorization, rate limiting, and more. It also integrates well with Identity Server. In my eyes, the biggest advantage of Ocelot is that you create the .NET project yourself, install a NuGet package, configure your gateway, and then deploy it like any other ASP.NET Core application. Since Ocelot is written in .NET, extending it if needed or contributing to the project or its ecosystem is easier.To quote their GitHub README.md file: « YARP is a reverse proxy toolkit for building fast proxy servers in .NET using the infrastructure from ASP.NET and .NET. The key differentiator for YARP is that it’s been designed to be easily customized and tweaked to match the specific needs of each deployment scenario. »Envoy is an « open source edge and service proxy, designed for cloud-native applications », to quote their website. Envoy is a Cloud Native Computing Foundation (CNCF) graduated project originally created by Lyft. Envoy was designed to run as a separate process from your application, allowing it to work with any programming language. Envoy can serve as a gateway and has an extendable design through TCP/UDP and HTTP filters, supports HTTP/2 and HTTP/3, gRPC, and more.Which offering to choose? If you are looking for a fully managed service, look at the cloud provider’s offering of your choice. Consider YARP or Ocelot if you are looking for a configurable reverse proxy or gateway that supports the patterns covered in this chapter. If you have complex use cases that Ocelot does not support, you can look into Envoy, a proven offering with many advanced capabilities. Please remember that these are just a few possibilities that can play the role of a gateway in a microservices architecture system and are not intended to be a complete list.Now, let’s see how gateways can help us follow the SOLID principles at cloud-scale:
- S: A gateway can handle routing, aggregation, and other similar logic that would otherwise be implemented in different components or applications.
- O: I see many ways to tackle this one, but here are two takes on this:
- Externally, a gateway could reroute its sub-requests to new URIs without its consumers knowing about it, as long as its contract does not change.
- Internally, a gateway could load its rules from configurations, allowing it to change without updating its code.
- L: N/A
- I: Since a backend for frontend gateway serves a single frontend system, one contract (interface) per frontend system leads to multiple smaller interfaces instead of one big general-purpose gateway.
- D: We could see a gateway as an abstraction, hiding the real microservices (implementations) and inverting the dependency flow.
Next, we build a BFF and evolve e-commerce application from Chapter 18.
