Skip to content

PATTERN Cited by 1 source

Centralised backend proxy for micro-frontends

Problem

A micro-frontend deployment has N independently built and deployed frontend bundles, each potentially needing to call M backend microservices. Left alone, every bundle implements its own authentication flow, token handling, and permission checks, and every microservice implements its own authorisation logic for every caller it trusts. The result:

  • Auth drift across remotes — each team's bundle handles session cookies / OIDC / token refresh slightly differently. Bugs recur per team.
  • Authorisation scattered across backend services — each microservice decides which scopes it trusts for which operation. Policy changes touch every service.
  • Secrets in the browser — client-side tokens end up with broad scopes because narrowing them per-call is expensive without a server-side mediator.
  • No single place to enforce rate limits, audit logs, or cross-request correlation.

Solution

Place a portal-owned backend proxy between every micro-frontend and every microservice. The proxy is the single auth+authz gatekeeper:

  • No remote calls microservices directly. All backend traffic from any bundle passes through the proxy.
  • The proxy authenticates the user once (typically via an OIDC / session cookie). Individual remotes do not implement authentication flows.
  • The proxy authorises each forward. It holds the user's permission scopes and checks them against the target microservice call. Microservices receive already- authorised requests and focus on their core logic.
  • The proxy normalises cross-cutting concerns — rate limits, retries, logging, tracing, error shapes.

The proxy is usually same-origin with the shell (to share session cookies) and is deployed once, owned by the portal team, not per-remote.

Trade-offs

Pro - One implementation of auth vs. N. - Microservices do not need to trust every remote's token handling. - Cross-cutting concerns (rate limit, audit, tracing) have one home. - Front-end traffic shape is controllable — the proxy can reject misbehaving calls regardless of which remote issued them.

Con - The proxy is a platform-team deployment dependency for every remote team — contention on roadmap. - Latency floor — one more hop for every backend call. - The proxy is a blast-radius concentration point — a bug or outage in the proxy affects every remote's backend access simultaneously. - Some routes are naturally direct (static assets, third-party SaaS that needs user-agent isolation); the proxy-for-everything posture must carve exceptions.

Relationship to BFF

A centralised backend proxy is architecturally adjacent to a backend-for-frontend: both sit between the frontend and microservices. The distinctions:

  • A BFF typically aggregates data and shapes responses for a specific frontend. The backend proxy in this pattern is a transparent gatekeeper — no response shaping, no aggregation, only authentication + authorisation + forwarding.
  • A BFF is often duplicated per frontend surface (web BFF, mobile BFF). The centralised backend proxy is one per micro-frontend deployment, serving all remotes.

In practice the two can coexist: a proxy handles auth; a BFF handles data shape.

Seen in

  • sources/2024-10-16-zalando-building-a-modular-portal-with-webpack-module-federation — canonical wiki instance. Zalando's Logistics Portal puts "a centralised backend proxy within the portal to handle both authentication and authorisation. This proxy acts as a gatekeeper for all requests coming from the frontend, ensuring that no direct access to backend services occurs without proper authentication and authorisation checks." The proxy authenticates once, holds user permission scopes, and forwards only authorised requests. Each microservice "focuses on its core functionality without worrying about authorisation logic." Paired with patterns/manifest-driven-micro-frontend-loading — the proxy's /applications endpoint is also the application-discovery entrypoint.
Last updated · 550 distilled / 1,221 read