Multi-tenant portal frontend

Intent

This pattern assumes a multi-tenant API that already enforces which client and which user can see what, as in multi-tenant API. It builds one web app over that API for every client: one build promoted through every environment, every backend call made through a typed client, and navigation driven by each client's features and each user's groups. This enables three outcomes:

1. The build you tested in staging is the build that ships.
2. Each client sees only the features they've bought, without feature checks copied into every page.
3. A front-end mistake can show the wrong menu, but not the wrong data, because the API decides what data leaves the server.

Motivation

A tenant portal built quickly tends to fail in three ways:

1. Environment values are baked into the bundle. Each environment then needs its own build, so what you tested isn't what ships. The twelve-factor app keeps configuration in the environment for this reason.
2. API calls spread through components. Authentication and error handling get copied from page to page, and one change to the API means hunting through all of them.
3. Feature checks are copied into every page, where they drift apart, until nobody can say what a given client should see.

This pattern keeps the portal a thin layer over the API. The API stays the only place that decides what a client or user may see, and the portal reflects those decisions rather than repeating them: its navigation follows each client's features and each user's groups, so hiding a page is never what protects it. Configuration is read from the environment when the app starts, and each client's branding is loaded with that client's record from the API, so one build serves every client in every environment, and a new client's look needs no release.

Applicability

Use this pattern when:

1. One web app serves many tenants, each seeing only the features they've bought.
2. The backend is an authenticated API, and the app is mostly screens over it.
3. The same build must run in every environment, promoted rather than rebuilt.

Do not use this pattern when:

1. It's a single-tenant internal tool, where feature gating and themes are overhead.

Structure

Participants

Constraints and trade-offs

1. The app fetches its configuration before it can sign anyone in, which adds a round trip before the first screen.
2. The app can't know a user's client until they sign in, so the sign-in screen is unbranded unless each client has its own address.

Part of how I deliver

When a platform's clients need to see their own product, this is how I build the front of it. It's one of many patterns I bring through contract delivery, and it keeps the portal simple enough for your own team to carry on with.

Related