Since lesson 4.12.1 the Kladde has two applications, and with every further service the browser would have to know one more address. Each of them would need its own TLS material, its own rules for sign-in and rate limiting and its own entry in every firewall. An API gateway collects that in one place: one entrance for many services. This lesson builds it with YARP, Microsoft's reverse proxy library for ASP.NET Core.
What a gateway takes over
Microsoft's guide to API gateways in the Azure Architecture Center names three tasks a gateway can take over:
- Routing (gateway routing): Forward requests by path, host or method to the right service. The browser knows one address, and the services behind it can move, split or grow together.
- Aggregation (gateway aggregation): Combine several answers into one. That saves a client many small calls.
- Cross-cutting concerns (gateway offloading): Check sign-in, limit rates, terminate TLS, clean headers, log. What every service would need stands once at the entrance.
Two things don't belong in the gateway. Business rules: A gateway that decides whether a quote may be sent is a second monolith at the entrance. And sole trust: If only the gateway checks the sign-in and the services behind it trust anyone who reaches them, one mistake in the network is enough for a break-in. According to zero trust from lesson 4.8.1, every service checks for itself; the gateway is one more check, not the only one.