By the end of the lesson, you can distinguish the roles of the reverse proxy, the API gateway and the BFF, and list the advantages and costs of a common entry point.
Why is it needed?
With several services the client has to find its way to the right service somehow. According to the Azure description, with direct calls the client code becomes complex (it has to track several endpoints and handle failures), the client is tied to the decomposition of the backend, more network round trips add latency, every public service must handle authentication and limiting separately, and the attack surface grows.
Roles
The reverse proxy stands in front of the servers and forwards incoming requests. It can hide internal addresses, terminate the TLS connection and handle several targets.
The API gateway is the common entry point of the APIs. According to Azure it works as a reverse proxy, routes requests to the appropriate service and can perform cross-cutting tasks as well: authentication, TLS termination, mutual TLS, rate limiting. In the words of microservices.io the pattern is "the single entry point for all clients": it either routes to one service or fans out to several.
Azure distinguishes three gateway patterns:
Routing: layer-7 routing, a single endpoint for the client;
Aggregation: merging several requests into one reduces the chattiness between the client and the services;
Offloading: moving common tasks (TLS, authentication, limiting, logging, caching…) out of the services.
One product can fill several roles, so in an architecture name the function, not the product.
flowchart LR
C["External client"] --> G["Gateway: entry rules"]
G --> R{"By path"}
R -->|"/a"| A["Service A"]
R -->|"/b"| B["Service B"]
Routing
The target can be chosen by host, path or explicit version (by the Envoy description, for example by path and authority). The rules must be applied in an unambiguous order; a pattern that is too general can swallow a concrete path. With path rewriting it must be clear what the internal service sees. Headers forwarded by the gateway are trust questions: a "user" or "role" header supplied by an external client must not become a trusted context.
BFF and aggregation
The BFF is a server-side layer fitted to the needs of a given client. According to microservices.io, in the BFF pattern there is a separate gateway per kind of client (for example web, mobile and external partner); each gives an API tailored to its own client. The tasks of the BFF: assembling a response from several services (API composition), turning internal errors into states the client can handle, and reducing the size of the response.
Important rules:
A missing mandatory piece of data means an error; missing optional data means a marked partial response; the contract must make this visible, otherwise the client confuses "there is no review" with "it could not be fetched".
The assembled data may come from different moments; a summary read does not replace the final decision at the owner.
The web and mobile BFF may change separately, but they should not copy common business rules.
For a personalised response, the cache key must include the context affecting the response, otherwise a shared cache is forbidden.
API composition collects data at request time; a read model (4.3) is a pre-processed copy. The choice depends on freshness and availability requirements.
Advantage and price
The client has to know fewer addresses and authentication connections; the internal decomposition can change while the public API stays stable; common rules can be enforced in one place. The price: an extra hop, a common dependency, own capacity and availability. According to Azure, the gateway must not become a single point of failure or a bottleneck (the description of the Strangler Fig pattern warns about this too). If every business process moves into the gateway/BFF, a new central coordinator, a small monolith, forms in front of the services.
Characteristics (from the communication point of view)
Aspect
Gateway / BFF
Direction
Passes through: inbound from the client, the response back
Initiator
The client
Connection persistence
Per request, or per the protocol the client uses
Latency
One extra hop; with aggregation it can decrease counted in client round trips
Load
Concentrates traffic; needs its own capacity
Fault tolerance
It can be a single point; the rule of the partial response must be given
When it fits
Many services, differing clients, common cross-cutting rules
When it does not
A single service; if business logic leaks into the gateway
Common misconceptions
Statement
Clarification
"Reverse proxy, gateway and load balancer are separate servers."
Roles; one product can fill several.
"The BFF is a new data owner."
It assembles and translates; the data belongs to the services.
"A request that passed the gateway is trustworthy."
Client headers must not be taken as trusted.
"One gateway is good for every client."
Because of differing client needs, a BFF per client is possible.
In short
The reverse proxy forwards, the API gateway is the common entry point and home of cross-cutting tasks, the BFF is a layer fitted to the client.
Reverse Proxy, API Gateway and BFF
Objectives
By the end of the lesson, you can distinguish the roles of the reverse proxy, the API gateway and the BFF, and list the advantages and costs of a common entry point.
Why is it needed?
With several services the client has to find its way to the right service somehow. According to the Azure description, with direct calls the client code becomes complex (it has to track several endpoints and handle failures), the client is tied to the decomposition of the backend, more network round trips add latency, every public service must handle authentication and limiting separately, and the attack surface grows.
Roles
The reverse proxy stands in front of the servers and forwards incoming requests. It can hide internal addresses, terminate the TLS connection and handle several targets.
The API gateway is the common entry point of the APIs. According to Azure it works as a reverse proxy, routes requests to the appropriate service and can perform cross-cutting tasks as well: authentication, TLS termination, mutual TLS, rate limiting. In the words of microservices.io the pattern is "the single entry point for all clients": it either routes to one service or fans out to several.
Azure distinguishes three gateway patterns:
One product can fill several roles, so in an architecture name the function, not the product.
flowchart LR C["External client"] --> G["Gateway: entry rules"] G --> R{"By path"} R -->|"/a"| A["Service A"] R -->|"/b"| B["Service B"]Routing
The target can be chosen by host, path or explicit version (by the Envoy description, for example by path and authority). The rules must be applied in an unambiguous order; a pattern that is too general can swallow a concrete path. With path rewriting it must be clear what the internal service sees. Headers forwarded by the gateway are trust questions: a "user" or "role" header supplied by an external client must not become a trusted context.
BFF and aggregation
The BFF is a server-side layer fitted to the needs of a given client. According to microservices.io, in the BFF pattern there is a separate gateway per kind of client (for example web, mobile and external partner); each gives an API tailored to its own client. The tasks of the BFF: assembling a response from several services (API composition), turning internal errors into states the client can handle, and reducing the size of the response.
Important rules:
API composition collects data at request time; a read model (4.3) is a pre-processed copy. The choice depends on freshness and availability requirements.
Advantage and price
The client has to know fewer addresses and authentication connections; the internal decomposition can change while the public API stays stable; common rules can be enforced in one place. The price: an extra hop, a common dependency, own capacity and availability. According to Azure, the gateway must not become a single point of failure or a bottleneck (the description of the Strangler Fig pattern warns about this too). If every business process moves into the gateway/BFF, a new central coordinator, a small monolith, forms in front of the services.
Characteristics (from the communication point of view)
Common misconceptions
In short
Review questions
Learning resources