Since 02-02 we have been talking about an API Gateway on port 8080 "in front of" the services: it is the piece that makes the strangler fig possible (the web keeps calling a single address while routes move from the monolith to the services) and the only door that the web, the mobile app and external partners will ever see. In 03-03 we also left two questions open: where the GraphQL that aggregates Orders and Catalog for the mobile app lives, and why we talk about a backend for frontend. This lesson answers both.

We will look at which problems a gateway solves (one entry point, not exposing the 300x ports, and the cross-cutting responsibilities: routing, delegated authentication, rate limiting, CORS, TLS termination, aggregation, logging), what it should not do, TechCorp's gateway route table and its role in the strangler fig, the implementation options, a minimal but complete gateway in Express with http-proxy-middleware explained step by step, the equivalent declarative configuration in Traefik, the Backend for Frontend pattern with a mobile BFF that composes GET /orders/{id} + GET /products?ids=, and the gateway's risks. How the gateway finds the services (discovery and load balancing) belongs to 03-05, authentication in detail to 07-01 and the gateway's deployment to module 5.

1. The problem: many services, a single client
2. Cross-cutting responsibilities of the gateway
3. What a gateway must NOT do
4. TechCorp's gateway routes and the strangler fig
5. Implementation options
6. A minimal gateway in Express with http-proxy-middleware
7. The same configuration in Traefik (declarative YAML)
8. The Backend for Frontend pattern
9. A mobile BFF that composes order and products
10. Gateway risks

Without a gateway, TechCorp's web would have to know that products live at catalog-service:3001, orders at orders-service:3002 and customers at customers-service:3004. That brings five immediate problems:

1. Client coupling to the topology. Every time a service changes host, is split or merged, the web has to be redeployed and a new version of the mobile app published (and then you wait for users to update).
2. Attack surface. Exposing six ports to the Internet means exposing six surfaces to authenticate, patch and monitor. Inventory and Payments, moreover, must not be reachable from outside under any circumstances.
3. Duplication of cross-cutting concerns. Authentication, CORS, request limits, TLS, access logging: either every service does it (six times, with six slightly different versions) or someone in front of all of them does.
4. Many network round trips. A screen that needs data from three services makes three requests from the phone, each with its latency and its handshake.
5. The strangler fig is impossible. If the web talks directly to the monolith, moving /products to the new service requires changing the web. With a gateway, you change one routing rule and nobody else notices.

An API Gateway is a server that receives all external requests and forwards them to the appropriate internal service, applying the common policies along the way. It is a reverse proxy with judgment.

The services with a dashed outline have no route in the gateway: they only talk through events (03-02) or receive internal calls.

In 02-01 we formulated "smart endpoints, dumb pipes": the intelligence lives in the services; the pipes (broker, gateway) only move messages. Applied to the gateway:

• No business logic. The gateway does not compute totals, does not validate that an order has lines, does not decide whether a customer may order. If it does, it becomes a mini-monolith that every team must touch for any change, and the worst organizational bottleneck.
• It does not access the services' databases. Not even for "a quick query".
• It does not transform business payloads (renaming price to precio for one client). That is a BFF (section 8) or an API version (03-06).
• It does not orchestrate sagas. The order flow lives in the services and in RabbitMQ.
• It does not replace each service's security. The gateway authenticating does not exempt Orders from checking that the order belongs to whoever is asking for it (07-01: defense in depth).

The litmus test: if changing a business rule requires redeploying the gateway, the rule is in the wrong place.

Route table in the current state of the plan (Catalog, Orders and Customers already extracted or being extracted):

The strangler fig is visible in the last /api/* row: at the start of the project everything went to the monolith. The Platform team added the /api/products/* rule when Catalog was ready; it will add /api/orders/* when Orders is, and so on until the monolith rule receives no traffic and is deleted. Each step is a gateway configuration change, reversible in seconds: if the new Catalog fails, /api/products/* is pointed back at the monolith.

Two conventions: public routes carry the /api/ prefix to tell them apart from the web's static assets, and the gateway strips that prefix before forwarding, so that services expose /products, /orders, exactly as in the contracts from 03-01, without knowing there is a gateway in front.

TechCorp's strategy: understand the gateway by building a minimal one in Node.js (section 6), operate a declarative one in production (Traefik, section 7; in Kubernetes it will act as the Ingress, 05-02), and program only the BFFs, which do have legitimate composition logic.

Explanation of the decisions:

• There is no express.json(). The gateway does not need to parse bodies: it forwards them as is, as a stream. Parsing them would cost CPU and break the transmission of large bodies. When in a real project a global express.json() gets added "out of habit", http-proxy-middleware stops forwarding the body and every POST arrives empty: it is the classic mistake.
• pathRewrite is the translation between the public contract (/api/orders) and the internal one (/orders). The services do not know there is a prefix.
• proxyTimeout: 5000 is the minimum good practice we talk about in every lesson; without it, a hung Catalog holds gateway connections until they run out. Retries and the circuit breaker belong to 06-03.
• The order of the routes implements the strangler fig: specific ones first, the catch-all to the monolith last. Migrating a route means adding one line above the catch-all.
• requireToken is a skeleton: in 07-01 it will verify signature, expiry and audience of the Keycloak JWT and pass the identity on to the service.
• The proxy's error responds in the same RFC 7807 format from 03-01, with the requestId so that support can look it up in the logs.

Manual test of our usual order through the gateway (with Orders listening on 3002):

It should return 202 Accepted, Location: /orders/ord-88213 (the service builds the internal path; the gateway could rewrite it to /api/orders/... with an onProxyRes, or the client adds the prefix; TechCorp opts for the client knowing the /api prefix), and X-Request-Id.

In production, maintaining a hand-written gateway does not pay off: Traefik does the same with YAML. Its model has three concepts: routers (which requests I capture: host and path rules), middlewares (what I do to them: strip prefix, limit, headers) and services (where I send them, with load balancing). Dynamic configuration equivalent to the gateway above:

And the minimal static configuration (ports, and in production TLS with Let's Encrypt, whose certificate side is covered in 07-02):

Correspondence with the Express code: each app.use('/api/x', ...) is a router + stripPrefix; express-rate-limit is the rateLimit middleware; requireToken is forwardAuth; the catch-all to the monolith is the router with priority: 1; and TARGETS are the services. When in 05-02 we deploy to Kubernetes, these services will point to the cluster's Service objects and Traefik will discover them on its own (03-05 explains how).

A gateway serves all clients alike. But the desktop web, the mobile app and a partner's ERP need different things: the app wants small, composed responses (one screen, one request); the web tolerates several calls and wants caching; the partner wants stable, documented REST. If the gateway tries to please everyone with transformations and aggregations, it bloats (risk from section 10).

The Backend for Frontend (BFF) pattern proposes one facade service per type of client, owned by the team that builds that client: bff-mobile is maintained by the app team; bff-web, by the web team. Each BFF composes and adapts the services' APIs to the needs of its front end, and only that one.

At TechCorp: the gateway routes /api/graphql to bff-mobile:3010 (table in section 4). The web, for now, consumes the REST services directly through the gateway; if its screens get complicated, it will get its bff-web. The partners' ERP uses the public REST API without a BFF.

The app's "order detail" screen needs the order (Orders) and the image and current availability of each product (Catalog). In 03-03 we solved it with GraphQL + DataLoader, and that code is exactly the mobile BFF. Here we show the REST alternative, simpler, to make the composition idea clear; both are valid and TechCorp will try REST first and move to GraphQL when the screens call for it.

What makes this code legitimate in a BFF and not in the gateway: it knows which screen calls it, decides what to degrade if a dependency fails, translates statuses into texts and fields into front-end names. All of that is presentation knowledge, not business knowledge (the BFF does not change the order status or recompute totals), and it belongs to the app team. When the app has five screens like this, the GraphQL schema from 03-03 will replace five composition routes with a single flexible endpoint.

• Global express.json() in the gateway. It consumes the body stream and the proxy forwards empty POSTs. If you need to parse in some route of the gateway's own, do it only on that route.
• Routes in the wrong order. The /api catch-all before /api/orders captures everything and the strangler fig stops working. Specific first, catch-all last (or priority in Traefik).
• No timeout on the proxy. A hung service exhausts the gateway's connections and takes down the entire API. proxyTimeout always.
• CORS "everywhere". With origin: '*' and credentials, the browser rejects it and you also open the API to any website. Allowlist of origins.
• Rate limit in memory with several replicas. Each replica counts on its own and the real limit is N times higher. Shared store as soon as there is more than one instance.
• Exposing Inventory and Payments "for debugging" with a temporary route. Temporary routes stay. To debug, kubectl port-forward (05-02) or the internal admin panel.
• Putting aggregation in the gateway "because it is just one screen". The second screen arrives in a week. BFF from the first one.
• One BFF shared between web and mobile. It stops being "for frontend": it becomes a fat gateway under another name. One per type of client.
• Forgetting to expose headers in CORS (exposedHeaders). The browser hides Location, ETag and X-Request-Id from the web even though the server sends them, and the polling after the 202 cannot find the URL.

Exercise 1. The Orders team has finished the extraction and /api/orders/* already points to the new service. Now it is /api/customers/*'s turn, but Marta asks for a cautious rollout: for one week, only requests with the header X-Canary: customers should go to customers-service:3004; the rest, to the monolith. Write the change to the Express gateway (a router function of http-proxy-middleware or a preceding middleware) and explain how you would revert it in seconds. Mention which lesson of the course covers this kind of deployment in general.

Exercise 2. The mobile app needs a "my latest orders" screen that shows, for each of the customer's last 10 orders, its status, total and the image of the first product. Design the mobile BFF route (GET /mobile/my-orders), state which internal calls it makes (with the contracts from 03-01), how many there are in total with and without batching, and write the example JSON response with two orders.

Exercise 3. A developer proposes adding a check to the gateway: "if the POST /api/orders carries more than 50 lines, reject it with 422 before it reaches Orders, so we protect the service". Argue whether it is the responsibility of the gateway, of the Orders service, or of both, and which version of that idea would be acceptable in the gateway.

Solution 1.

http-proxy-middleware accepts in router a function that returns the target per request:

It has to be declared before the /api catch-all. Rollback: change router so it always returns TARGETS.monolith (or remove the route and let the catch-all absorb it) and redeploy the gateway, or, in Traefik, edit the router with watch: true without a restart. When the week ends well, the condition is removed and /api/customers always goes to the new service. This is a header-driven canary deployment; deployment strategies (rolling, blue-green, canary by traffic percentage) are covered in 05-04.

Solution 2.

Route: GET /mobile/my-orders (the customer comes from the JWT; in 07-01 the gateway or the BFF extract it). Internal calls:

1. GET /orders?customerId=c-1024&sort=-createdAt&limit=10 to Orders (cursor pagination from 03-01) → 1 call.
2. Collect the productId of the first line of each order (up to 10 ids, deduplicated) and call GET /products?ids=p-501,p-777,... on Catalog → 1 call.

Total: 2 calls with batching; 11 without (1 + one per order). Response:

If Catalog fails, imageUrl becomes null and the list is shown all the same (degradation decided by the BFF).

Solution 3.

The rule "at most 50 lines per order" is a business rule of the Order aggregate (02-03): the Orders service decides and enforces it, responding 422 INVALID_DATA according to its contract (03-01). If it lives in the gateway, the day the business changes the limit to 100 the gateway will have to be redeployed, and Luis's team will depend on Platform for a rule of their own; besides, an internal POST /reservations or the admin panel, which do not go through the gateway, would not enforce it. It is exactly the "fat" gateway from section 10.

What is acceptable in the gateway is a cross-cutting protection with no business semantics: a body size limit (for example, 256 KB for any POST, with 413 Payload Too Large) that protects every service from giant bodies without knowing what an "order line" is. The service keeps validating the 50 lines; the gateway just prevents 50 MB from reaching it.

The API Gateway on port 8080 is TechCorp's only door: it routes the public routes /api/products, /api/orders and /api/customers to their services (and the rest, less and less, to the monolith, which is the strangler fig in action), and concentrates the cross-cutting concerns: correlation with X-Request-Id, CORS, rate limiting, delegated authentication, timeouts and access logging. We built it in Express with http-proxy-middleware to understand it and declared it in Traefik to operate it. And we clearly separated what does not belong to it (business logic, bespoke aggregations) and whom it does belong to: the backends for frontend, one per type of client, maintained by the front-end team, where both the REST composition of bff-mobile and the GraphQL from 03-03 fit. Inventory, Payments and Notifications have no public route: they only talk through events.

Now, throughout the code in this lesson we have written targets like http://catalog-service:3001 as if they were fixed addresses. They are not: in production there will be eight replicas of Catalog at the peaks, each with an ephemeral IP that Kubernetes assigns and destroys. Which one does the gateway call? And Orders, when it queries the catalog? How does anyone know which instances are alive and which are not? That is service discovery and load balancing, the next lesson.