FlowFrame

FlowFrame

← Academy

API Gateways

Centralized entry points for microservices routing

This is the most complex scenario — let's meet all the players:

💻 Client

Sends 3 different requests — each targeting different API paths:

- GET /api/v1/posts/list — a posts query

- GET /api/v1/users/profile — a users query

- GET /api/v1/posts/list — another posts query

🚪 API Gateway

The single entry point for all client requests. It looks at the URL path and decides: *"Which backend service should handle this?"* See details under API Gateway.

🖥️ Post Server

Only handles /api/v1/posts/* endpoints. Ignores anything else.

🖥️ User Server

Only handles /api/v1/users/* endpoints. Ignores anything else.

Flow: Client → API Gateway → (Post Server or User Server)

The gateway reads the path prefix and routes accordingly — like a smart switchboard.

In a [microservices architecture](/learn/glossary/microservices), you might have dozens of specialized services — a user service, payment service, notification service, etc. Each lives at a different address.

Without an API Gateway:

- The client must know the exact address of every service.

- When a service moves or scales, every client has to update.

- Cross-cutting concerns (authentication, rate limiting, logging) must be implemented in every service.

With an API Gateway:

- Clients talk to ONE address — the gateway.

- The gateway handles all routing transparently.

- Authentication, rate limiting, and logging happen in one place.

What the Gateway Does

  • Routing — Matches path prefixes to backend services.
  • Security — Can validate auth tokens before forwarding requests.
  • Rate Limiting — Prevents any client from flooding the backend.
  • [Load Balancing](/learn/glossary/load-balancer) — Distributes across multiple servers in a service pool.

    • Press Play to watch requests fan out to the correct servers!

    The gateway uses a routing table to match incoming paths to backend services:

    Path Prefix→ Service/api/v1/postsPOST_SERVICE/api/v1/usersUSER_SERVICE

    When a request arrives:

  • Gateway reads the URL path.
  • Finds the longest matching prefix in the routing table.
  • Forwards the request to the matching service pool.
  • If no rule matches → returns 404 Not Found. See Status Codes.
  • If the method isn't allowed → returns 405 Method Not Allowed.

    • Service Pools

    Each "service" in the gateway is actually a *pool of servers*. In our sim:

    - POST_SERVICE → Post Server

    - USER_SERVICE → User Server

    If you added more Post Servers and connected them, the gateway would load-balance across all of them.

    Interactive Checkpoints

    ▶ Misconfigure Routes (See a 405 Error)

    Apply

    Click to point all posts routes to USER_SERVICE. The User Server only handles /users endpoints, so /posts requests will get Method Not Allowed errors. Watch the error frames!

    Create your own API Gateway architecture:

    🛠️ Step-by-Step

  • Open the Interactive Sandbox in a new tab.
  • Add a Client — set up a request to /api/v1/users/me with method GET.
  • Add an API Gateway — connect Client → Gateway.
  • Add a Server (rename it "User Server").
  • Connect Gateway → User Server.
  • Select the Gateway in the inspector, and add a route rule: /api/v1/users → USER_SERVICE.
  • Assign User Server to the USER_SERVICE pool.
  • Click the Client to simulate — watch the gateway route the request correctly!

    • Bonus: Add a second server for a different path and see the gateway route to the right one.

    🛠️

    Now Try It Yourself!

    Head to the Interactive Sandbox and build this architecture from scratch — drag, drop, connect, and simulate.

    Open Interactive Sandbox

    Opens in a new tab

    Running1/0
    React Flow

    No frames available