frontend-patterns/research/walkthroughs/VC06-MicrofrontendEstate.md

118 lines
8.2 KiB
Markdown
Raw Normal View History

# VC-06 — Microfrontend estate
Status: provisional draft, editorial self-review only. Codex, 2026-09-26.
Synthetic fixed brief; exploratory preparation under WP-0003 T01/T02, not M2 acceptance.
Corpus: seventeen research hypotheses; no canonical admission.
## Fixed brief and assumptions
Independent teams/releases, shared navigation and partial outages are the fixed
constraints. For this exercise, assume a host shell with two capabilities, Reports
and Account, served in one browser context. Each team should release a compatible
change without rebuilding the host or the other capability. Host owns top-level route
selection and persistent navigation; teams own declared subroutes and lifecycle cleanup.
The service remains authoritative for protected data and writes. Offline edits,
collaborative editing and numerical latency budgets are unspecified and not promised.
Keyboard/focus continuity, meaningful load/error feedback and usable navigation during
a feature load failure are required. Separate bundles confer no authorization or
security isolation. Authentication/session policy, dependency versions, event schemas
and route collisions are integration contracts. This brief does not require a specific
framework, separate repositories, or separate origins.
## Baseline narrative without the pattern catalog
Produce a versioned artifact for each capability and load it through a host-selected
binding. Define mount/unmount, inputs/events and supported host/API versions. Keep
routing and shared state small enough that compatible feature changes do not force
all teams to release together. Publish before activating; retain prior compatible
artifacts and declare how old tabs continue operating. Show a local load failure while
keeping navigation available. Test dependency failures that can still affect the host.
The same obligations can be expressed without pattern names; no decision benefit is proven.
## Decisions
| Order | Context / forces | Pattern reference | Alternative / reason | Resulting context | Evidence |
| --- | --- | --- | --- | --- | --- |
| 1 | Independent release cadence versus integration cost | [Independent Feature Boundary](../candidates/IndependentFeatureBoundary.md) | One application release violates the assumed cadence; source folders alone cannot satisfy it | Separate artifacts plus explicit composition/activation contract | D04–D06/D08 |
| 2 | Local change cohesion versus shared dependencies | [Vertical Feature Slice](../candidates/VerticalFeatureSlice.md) | Global technical folders can scatter capability changes; do not force every shared primitive into a feature | Internal code organization can vary independently of release packaging | D01–D03 |
| 3 | Shared navigation and deep links | [URL-addressable State](../candidates/URLAddressableState.md), host-owned route context | Uncoordinated routers can disagree; a shared route schema still needs compatibility | Host selects capability; feature owns a declared subroute space | D04, editorial proposal |
| 4 | Partial outage versus coherent experience | [Failure Boundary](../candidates/FailureBoundary.md), scoped to load/render/lifecycle separately | A render boundary alone cannot handle a failed download | Host retains navigation and exposes a local error/retry path | D04/D06, runtime unverified |
| 5 | Independent activation versus version skew | Independent Feature Boundary | Upload-only is not activation; simultaneous incompatible upgrades defeat the stated independence | Supported version combinations and binding rollback defined | D05/D08/D09 |
D01–D09 resolve in the [source review](../reviews/FeatureDeploymentBoundaries.md).
Independent source, build, activation and failure boundaries are distinct decisions.
## Failure and recovery trace
1. Host H1 activates Reports R1 and Account A1 from a declared binding. Route and
public data/event contracts have tested compatibility ranges. This is an assumption
to be verified, not an observed guarantee of the example repositories.
2. Publish Reports R2 to a distinct retained URL, validate H1/R2/A1 and relevant API
combinations, then update only the Reports binding. Concurrent binding changes
need an atomic or conflict-detecting update contract.
3. A fresh session obtains R2; an open session may retain R1. Do not assume import-map
replacement hot-swaps existing modules. Define whether a session remains pinned,
reloads at a safe boundary or uses an explicit supported replacement protocol.
4. If R2 fails to load, keep shell navigation available and show an accessible feature
error. Retry identity here is a load concern; do not resubmit a domain mutation
merely because the feature remounts. Guard teardown callbacks from changing focus
or state owned by a newer instance.
5. If R2 requires an incompatible host/shared-state contract, do not claim independent
release. Reject activation or coordinate a migration with support for old sessions.
6. Roll back the Reports binding to retained R1 for applicable sessions. Verify API/data
compatibility before promising recovery; bytes alone cannot undo server effects.
A shared startup dependency outage is a separate scenario: local feature fallbacks
cannot protect a shell that never starts.
## Change one constraint
Replace independent releases with **one coordinated release cadence**; keep separate
teams, shared navigation and partial-outage requirements. Internal feature interfaces
and ownership can remain, but a single tested application artifact may now satisfy
the brief with less activation/version-skew machinery. Retain scoped failure handling;
do not infer it disappears when deployment units merge. This branch demonstrates why
Vertical Feature Slice need not imply Independent Feature Boundary.
## Review
| Criterion | Assessment | Reason |
| --- | --- | --- |
| Traceability | pass (editorial) | Pinned source mechanisms separated from proposed release contracts |
| Configuration coherence | pass (editorial) | Host routes, lifecycle and compatibility responsibilities explicit |
| Usefulness beyond baseline | unknown | Same-author synthesis; baseline already contains the obligations |
| Quality constraints | revise | No outage, keyboard/focus, old-session or rollback execution |
| Changed constraint | pass (editorial) | Single cadence permits combining artifacts while retaining code boundaries |
## Gaps and ownership
[WP-0003 T01/T02](../../workplans/FEP-WP-0003-contrasting-schools.md) owns a local
version-skew/load-failure/binding-rollback harness and independent walkthrough review.
No cloud deployment, production artifact activation or operational team independence
was verified. VC-04/05 remain planned; this draft does not complete VC-06's M2 gate.
## Executed model follow-up — 2026-09-26
[Seven-scenario native-module experiment](../reviews/FeatureReleaseExperiment.md)
now supports steps 2–6's publication/activation, version mismatch, failed loading and
session-scoped rollback distinctions in a synthetic host. Both browsers meet all seven
expected observations, including deliberate failures. Old lazy sessions need retained
artifacts even when loaded old sessions still work. Post-import compatibility gates
cannot prevent evaluation side effects. Shared startup outage is a separate fault scope.
This supersedes the lack of any load/rollback execution in the initial self-review,
but the quality criterion remains revise: browser focus/accessibility, unsaved work,
real API/data compatibility and independent review are still unverified. VC-06 stays
provisional; no production release or M2 acceptance is inferred.
## Activation/update-reload follow-up — 2026-09-26
[21 expected observations](../reviews/ActivationConflictsAndReload.md) now cover
stale binding writers and the application-controlled reload path with unfinished work.
Conditional replacement rejects stale maps; disjoint intent is explicitly reapplied,
while conflicting rollback awaits a decision. Preserve the latest authorized draft
before reload and revalidate its schema on the next document; a preflight check can
be invalidated by a later activation. Storage failure and unknown write outcome block
the fixture's reload. This does not establish distributed-map atomicity, native-unload
protection, backend acceptance, authorized retention or complete VC-06 validation.