API Gateways and Backends for Frontends

One front door

Clients should not need to know the address of every service. An API gateway is the single entry point: it routes requests to services, terminates TLS, authenticates tokens, applies rate limits and quotas, adds request IDs, and can aggregate responses. Managed options include AWS API Gateway, Azure API Management and Google Apigee; self-hosted options include Kong, NGINX, Envoy-based gateways and Spring Cloud Gateway. The Backend for Frontend (BFF) pattern adds one thin backend per client type (web, mobile app, partner API), owned by the team that builds that client, shaping and aggregating data exactly as that client needs. That avoids one generic gateway accumulating every client's special cases. Keep business logic out of the gateway; it should stay a thin, reliable edge, because every request depends on it.

Gateway and BFFs at the edge

Clients call one entry point; per-client BFFs shape responses; services stay behind.

Gateway routing configuration (Kong declarative)

Routes, authentication and rate limiting at the edge; services stay internal.

_format_version: "3.0"
services:
  - name: catalogue
    url: http://catalogue.internal:8080
    routes:
      - name: catalogue-route
        paths: [/api/catalogue]
  - name: checkout
    url: http://checkout.internal:8080
    routes:
      - name: checkout-route
        paths: [/api/checkout]
    plugins:
      - name: jwt
      - name: rate-limiting
        config:
          minute: 120
          policy: local

The gateway must not become a monolith

When every feature needs a gateway change, the gateway team becomes a bottleneck. Keep it to cross-cutting concerns and push client-specific logic into BFFs owned by client teams.

Quick check: What is the purpose of the Backend for Frontend pattern?

• Giving each client type its own thin backend that shapes data for that client
• Replacing all services with one backend
• Storing frontend assets in the database
• Running the frontend on the server