FRONTEND ARCHITECTURE DECISION

Same XYZ experience, two deployment and ownership models

Compare the optional Static Web Apps composition shell with a unified React web container on Azure Container Apps. The business-capability APIs remain on ACA in both options; the decision changes the frontend release boundary, runtime, and operating model.

Same UX Same ACA services Different frontend boundary

Decision scope: this is not a service-to-service architecture choice. It compares how the React experience is packaged, composed, deployed, scaled, and owned.

01 Side-by-side topology

Distributed frontend · optional flavor

SWA shell + micro apps

A stable shell owns chrome, routing, identity, design tokens, and named slots. Feature teams publish independently versioned bundles that the shell composes at runtime.

BrowserOne composed XYZ experience

Azure Static Web AppsComposition shell + edge delivery

Engagementremote bundle

XYZ gaugeremote bundle

Approvalsremote bundle

API Management + ACAGateway and capability services

Best fit

Multiple frontend teams need independent releases.
The shared shell PR queue is a measurable bottleneck.
Per-feature failure isolation offsets contract complexity.

Unified frontend · ACA hosted

Integrated web app on ACA

One React build contains the engagement, XYZ, and approval features. Nginx serves the SPA from one non-root container behind ACA ingress.

BrowserOne integrated XYZ experience

ACA external ingressHTTPS + revision traffic

React + Nginx containerEngagement + XYZ + approvals

API Management + ACAGateway and capability services

Best fit

One frontend team owns the whole user experience.
Operational simplicity is the primary constraint.
Features can share one coordinated release cadence.

02 Operating model comparison

The visible application is intentionally equivalent. The trade-off is autonomy versus platform and runtime complexity.

Dimension	SWA shell + micro apps	Integrated web app on ACA
Frontend deployment	Shell plus independently published remote bundles	One versioned OCI image
Release coordination	Per micro app; shell contract changes are coordinated	One frontend release and regression boundary
Runtime composition	Named slots and Module Federation	Direct React imports and one state tree
Frontend scaling	SWA edge distribution for static assets	ACA HTTP replicas; optional minimum replica to avoid cold start
Failure isolation	Per-slot error boundary can degrade one remote	One frontend revision is the failure boundary
Security surface	Remote provenance, CSP endpoints, and shared dependency governance	Container supply chain, ingress, Nginx, and image patching
Observability	Shell plus per-remote versions and telemetry	One frontend image and ACA revision
Operational load	More pipelines, contracts, pointers, and rollback paths	One build, image, health model, and rollback path
Primary advantage	Independent team delivery	Lower cognitive and operational overhead

03 Decision rule

Start unified; earn composition with evidence.

Choose the ACA web container while one team can safely own and release the frontend. Adopt the composition shell only when independent frontend teams, release contention, or blast-radius requirements create enough value to pay for runtime contracts and additional operations.

Not an either/or backend decision: both options can use the same APIM facade, ACA vertical slices, data stores, messaging backbone, identity controls, and observability platform.

04 Runnable samples

SWA shell + micro apps sample →Named slots, typed event contract, lazy feature bundles, and federation exposure. Integrated ACA web app sample →One React state tree, non-root Nginx image, ACA ingress, health probes, and scaling. SWA + Flex Functions sample →Independent remote SWAs and one FC1 TypeScript Function App per capability.

Launch locally: open the Runnable Samples launcher for startup commands and links to ports 5173, 5174, and 5175.

Citation scope: Azure service behavior is grounded in the workshop References. Runtime Module Federation and micro-frontend composition are general industry techniques, not Microsoft reference architectures.