API gateway, reverse proxy and BFF

Interviewers say: "You have a phone app, a website and five services. How do clients reach them?" A weak answer draws every box it has heard of. A strong answer says what each box does and costs, and when it is not needed.

Think about a hotel reception desk. The desk checks the room key and sends each guest to the right department.

A reverse proxy is a server in front of your servers. It passes each request to a server and returns the answer, so clients never see the real servers. (A forward proxy sits in front of clients instead.) It gives one address, removes the HTTPS lock (lesson 7), and can compress answers (lesson 27). A load balancer (lesson 28) is a reverse proxy that shares requests.

An API gateway is a reverse proxy for an API, with more jobs. It matters when you have several services (programs that others call, lesson 12). It:

• sends each path to its service: /orders to the orders service, /menu to the menu service;
• checks who the caller is once, so each service does not repeat it;
• refuses a caller who sends too many requests;
• writes one log, a record of each request.

Without it, clients need every service address, and each service repeats these jobs.

A backend for frontend (BFF) is a small server for one kind of client, such as the phone app. It calls the services and shapes the answer for that screen: one call from the phone, with only the fields the screen needs (lesson 12). Each client type gets its own BFF, often owned by the team that builds that client.

A common chain is: Client -> Load balancer -> Gateway -> BFF -> Services.

When it is overkill

Each box adds one hop (one more step for the request) and one more part that can stop. If a request must pass every box, all must be up, so you multiply the uptimes. With one service and one client, a load balancer is enough. A BFF is overkill with one client type, or when GraphQL (lesson 12) already lets each screen pick its fields.

The food app has a phone app and three services. Assumptions (made up to teach with): the phone round trip is 100 ms. A service needs 20 ms of work. A round trip inside the data centre is 0.5 ms (lesson 14). The BFF needs 5 ms to build its answer. Any other box adds 1 ms. Each box, with its spares, is up 99.9%, and failures are independent (lesson 28).

Part A: the BFF. The screen of lesson 12 needs the order, and then the customer and the items together. That is 2 stages.

• Phone calls services directly: 2 x (100 + 20) = 240 ms.
• Phone calls a BFF: 100 + 5 + 2 x (0.5 + 20) = 146 ms. We save 94 ms.

Part B: the boxes in a line.

• A load balancer alone: 0.001 x 43,200 = 43.2 minutes a month (lesson 28).
• Three boxes: 0.999 x 0.999 x 0.999 = 0.997003. Down: 0.002997 x 43,200 = 129.5 minutes. This answers the predict box.
• Time: 3 boxes x 1 ms = 3 ms more for every request.

For one service and one client, the gateway and BFF make the downtime 3 times larger and save nothing.

• A gateway solves one address and repeated jobs. It costs 1 ms and one more box that can stop. I would add it for several services, and use a load balancer alone for one.
• A BFF solves slow screens: 94 ms here. It costs one more service per client. I would skip it when all clients ask the same things.

"An API gateway is a load balancer." A load balancer shares requests between copies of one service. A gateway sends different paths to different services and does more jobs. One product may do both.

"Every system needs a gateway and a BFF." For one service they added 86 minutes of downtime (129.5 - 43.2) and 2 ms.

"The gateway is a good place for business rules." Every team then must change it. Keep it to jobs every request needs.

1. What does each of these do: a reverse proxy, an API gateway, a BFF?
2. Three boxes in a line are each up 99.95%. How many minutes of a 43,200-minute month are they down?
3. A team has one website and one service. A colleague wants a gateway and a BFF. What do you say?