Microservices & Micro Frontends End to End: From Browser Click to NestJS API Response
A practical end-to-end guide — shell host, Module Federation remotes, API gateway, NestJS microservices, shared SSO, and independent deploys. How micro frontends and microservices execute together in production SaaS.
- Micro Frontends
- Microservices
- NestJS
- Architecture
- SaaS

Micro frontends split the UI; microservices split the backend. End-to-end execution is what happens when a user clicks "Save" in a remote Admin bundle, the shell passes a JWT, the gateway routes to the tenant service, PostgreSQL commits, and the remote updates — without a monolith deploy. That path is the product: routing, auth, contracts, and release cadence aligned on both sides of the wire.
This guide walks that execution path step by step — distinct from high-level pattern catalogs. You will see how shell + remotes, gateway + services, and CI/CD pipelines cooperate so teams ship independently without breaking the whole SaaS.
The two halves of the same product
- Micro frontends — shell host loads remote bundles (Admin, Billing, Dashboard) at runtime via Module Federation or similar
- Microservices — NestJS services own domains (tenant, billing, notifications) behind one API gateway
- Shared contract — OpenAPI (or BFF schemas) + auth claims; remotes must not guess URLs per environment
- Independent releases — frontend v2.3 can ship while billing service v1.8 stays; compatibility rules prevent drift

End-to-end execution: one user action
- Navigate — user opens `/admin/tenants`; shell router loads the Admin remote entry (federated chunk)
- Auth — shell already holds Keycloak/OIDC session; remote receives token via shared auth module or BFF cookie
- Render — remote mounts React/Vue UI; calls `GET /api/tenants` through the gateway base URL from runtime config
- Gateway — validates JWT, attaches tenant + roles, routes to Tenant NestJS service
- Service — applies RBAC, queries PostgreSQL with tenant filter, returns JSON
- UI update — remote renders list; shell chrome (nav, layout) unchanged
- Deploy later — Admin team ships remote v1.4 to CDN; shell manifest points to new remote URL; backend unchanged
What the shell owns vs what remotes own
- Shell — layout, login/logout, top nav, runtime config, remote manifest, global error boundary
- Remotes — feature routes, forms, domain components, feature-specific API clients
- Neither remote should embed its own login page if SSO is platform-wide
Gateway: the front door for every remote
- All remotes use one public API origin — `/api/*` — so CORS and cookies stay simple
- Path-based routing: `/api/billing/*` → Billing service, `/api/tenants/*` → Tenant service
- Rate limits, tracing headers, and WAF live at the gateway — not duplicated in each remote
- Optional BFF layer if remotes need aggregated payloads; still one auth boundary
Independent deploy execution
- Frontend pipeline — build shell + remotes; upload federated assets to CDN/S3; update remote manifest version pins
- Backend pipeline — build NestJS images; run migrations as a job; rolling deploy per service
- Compatibility matrix — document which remote versions require which API schema versions
- Feature flags — hide a remote route until backend endpoint is live in production
- Smoke test: shell loads remotes + one CRUD path per critical domain after each release
Micro frontends without a gateway and shared auth is just multiple SPAs arguing about who owns the token.
Failure modes to plan for
- Remote fails to load — shell shows fallback UI; other remotes still work
- API version mismatch — contract tests between OpenAPI and remote API client
- Token expiry mid-session — shell refreshes; remotes subscribe to auth events
- Partial outage — billing service down; Admin remote shows degraded state, not a blank shell
Multi-tenant SaaS execution tips
- Tenant id from JWT only — remotes never send tenant in body without server validation
- Per-tenant branding can live in shell config; domain APIs stay tenant-filtered server-side
- Audit writes from any remote hit the same audit service through the gateway
What "done" looks like
Teams deploy Admin without redeploying Billing UI or the notification service, users never re-login between remotes, and every API call is traced gateway → service → DB. That is end-to-end execution, not just diagrams. Explore Cyber Infoware products or contact us for microservices and micro frontend delivery on NestJS SaaS.
Explore Cyber Infoware packages
Production NestJS SaaS foundations with commercial licensing — pick the architecture that matches your team.
- NestJS Microservice Starter Kit
Production NestJS microservices — API gateway, Keycloak SSO, RabbitMQ, Docker, Kubernetes, and Terraform.
- Enterprise SaaS Microservices Boilerplate
Full multi-tenant SaaS control plane as NestJS microservices — service-per-DB, billing, audit, notifications.
- Multi-Tenant SaaS Boilerplate
Best-seller NestJS multi-tenant SaaS boilerplate — one API, per-tenant databases, billing, and Keycloak SSO.