Application shell

The thin, long-lived container that hosts independently deployed micro-frontends and owns what none of them can own alone: configuration, authorization, composition and routing. From micro-frontends-migration.

The test of a good one

It should be “technology agnostic” and it should stop changing: “if you are capable of creating an application shell that doesn’t change very often after one year, you are in a good way.” Stability is the whole specification. A shell that keeps changing is a shell that has absorbed decisions belonging to the units it hosts, and every change to it is a change every team must accept.

Shell or composer

The first of the four decisions micro-frontends forces is application shell versus UI composer — a client-side host that loads units, or a server/edge component that assembles a response. It follows the rendering and routing choices rather than preceding them.

What sits beside it in a migration

The shell is not what makes a migration safe. That is the edge-compute routing layer: a Strangler Fig arrangement where the CDN decides per request whether a user gets the legacy monolith or the new unit, giving canary releases and rollback by configuration change rather than redeployment. The shell is the composition seam; the edge is the escape hatch. See micro-frontends-migration for the deployment-frequency figure attached to the second, not the first.

Related

micro-frontends · application-architecture · micro-frontends-migration · synthesis