Synthesis — Frontend Architecture

The evolving thesis. This spoke was spun out on 2026-08-12 at the curator’s approval, from three sources that sat in the hub’s holding pen over six weeks under the tag frontend-architecture: flutter-large-app-structure (parked 2026-06-30), micro-frontends-migration (2026-07-14) and open-saas (2026-08-10). Each had been declined by every existing spoke, and the declines are the charter — see CLAUDE.md → Scope boundary.

Current thesis

One question, three answers, and the question is not technical. The founding sources all address who decides an application’s structure, from three positions:

• the team, by convention — flutter-large-app-structure‘s feature-first-structure: capability at the top level, layers nested inside, features owning their own state.
• the organization, by ownership — micro-frontends-migration‘s micro-frontends: coarse-grained units, one team each, deployed independently.
• the framework, before anyone arrives — wasp through open-saas: a spec compiled into a whole application, its wiring not the author’s to arrange.

Read together they say the decision does not vanish when it is delegated. Adopting a boilerplate is a structural choice, made by someone the adopting team will never meet.

Boundaries beat patterns

The two architecture sources agree on a claim neither one demonstrates. flutter-large-app-structure: “Large applications rarely fail because they lack patterns. They fail because ownership boundaries become unclear.” micro-frontends-migration: micro-frontends optimize for independence, because “when you optimize for reusability, you create coupling.” One is talking about folders and the other about deployables, and they arrive at the same sentence.

They also agree on a specific corollary — global state is the enemy, and features or units should own their own. Both name roughly the same exceptions (authentication, theme, localization). Two sources at different scales, in different ecosystems, converging on one rule is the strongest signal this small corpus currently holds.

Enforcement is what separates the two scales

A micro-frontend boundary is enforced by deployment: crossing it requires a network call or a hard navigation. A feature-first-structure boundary is enforced by discipline: nothing stops an import except review, or a tool of the kind micro-frontends-migration names (ts-arch blocking unwanted imports, a bundle-size fitness function). The same thesis with two very different amounts of teeth, and no source here compares how well each holds.

The most useful number in the corpus is not about modularity

One team went from 3 deployments a month to 25 a day per team after a micro-frontend migration — and micro-frontends-migration attributes it to the “safe net” of edge-compute canaries and rollback by configuration change, not to the architecture. Read carefully, the spoke’s headline figure is evidence about reversibility. That is a caution against the reading everyone will want to make of it.

Duplication has a price, and one source pays it

“Duplication is far cheaper than the wrong abstraction” is a position, not a truism. The evidence offered is a shared header changed once in three years, against a team that spent four months shipping nothing to refactor global state. Thin, but it is arithmetic rather than taste, which is more than the rest of the domain manages.

The corpus’s own weak spot

This is a domain that argues rather than measures, and the founding corpus shows it plainly. Of three sources: one is a practitioner reporting migrations he ran, with figures and named failures (T2); one is a first-party repository stating what it ships (T1, and promotional by construction); and one cites nothing at all — no study, no case, no measurement, no codebase named (T3, and its own page says so).

So the pattern to watch for is not disagreement between sources but confidence without evidence. A structure diagram is not a finding. CLAUDE.md carries this as an edge rule: record what a source rests on, every time.

Open questions

• Does any of this reduce anything measurable? No source here reports a defect rate, a lead time, an incident count or a cognitive-load measure before and after a structural change. The one figure the corpus holds is a deployment frequency whose own author credits it to reversibility.
• Which enforcement actually holds? Deployment-enforced boundaries versus review-enforced ones, over time, on the same team. Both founding sources assume their own answer.
• What does a boilerplate cost later? open-saas pre-commits a dozen choices; nothing here describes a team hitting the limits of one, or the cost of leaving. The generous and the sceptical readings are equally unsupported.
• Why did Open SaaS choose what it chose? The decisions are inspectable and the reasoning is absent. A maintainer’s write-up would turn a template into an argument.
• Is the “micro-frontends are microservices for the frontend” analogy load-bearing or decorative? The talk borrows a distributed-systems mindset explicitly. Whether the backend literature’s findings transfer — or whether a frontend’s constraints (one shared DOM, one user, page-load budgets) break the analogy — is untested here. Cross-spoke seam with ../platform-ops-wiki.
• Where do React meta-frameworks sit? Next.js, Remix and Gatsby were exiled from ../static-site-wiki by charter and this spoke is now their home, with none of them paged. The spine says the framework decides the structure; the most widely adopted instances of that claim are absent.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. Any measured outcome of a structural choice. The spoke’s thesis is currently unfalsifiable. — needs: a T1/T2 before-and-after on one codebase — defect rate, lead time, incident count or a validated cognitive-load instrument — not another architecture guide.
2. The case against micro-frontends, from someone who tried them. Everything held is by an advocate. — needs: a published retrospective of a migration that was reversed or judged not worth it.
3. Enforcement compared. — needs: an account of architecture-testing in practice (ts-arch, dependency-cruiser, ArchUnit-style tools) with what it caught, or a study of import-boundary violation rates.

Coverage edges — things this spoke’s domain plainly includes and does not hold; an ordinary solid source closes any.

4. React meta-frameworks. Next.js, Remix and Gatsby: the most common answer to “the framework decides,” and absent. — needs: the frameworks’ own architecture documentation, one page each.
5. Monorepo versus polyrepo. micro-frontends-migration says the choice moves architecture, organization and culture together, and no page covers it. — needs: Nx or Turborepo documentation plus one migration account.
6. The modular monolith. The position that says don’t distribute, which the corpus needs in order for micro-frontends to be a choice rather than a default. — needs: a write-up arguing it, ideally with a codebase behind it.
7. Module Federation itself. Named repeatedly as the mechanism and never described. — needs: the project’s own documentation.

Contradictions / tensions

No factual conflicts yet — three sources at three scales, largely non-overlapping. The live tension is about genre, and it was live before the spoke existed: two founding sources are architecture guides that argue a thesis; open-saas is a template that embodies one silently, and the hub’s own park record noted that the same cluster had already excluded a build-along tutorial on exactly that distinction. The spin-out went ahead with the objection recorded rather than dissolved (boilerplate). Expect it to recur: this domain’s artifacts are guides, repositories and talks, and they support very different kinds of claim.

Cross-spoke adjacency

• ../ui-frameworks-wiki — the layer below. The component-versus-micro-frontend distinction is the seam, and micro-frontends-migration draws it explicitly.
• ../static-site-wiki — that spoke’s exiled React meta-frameworks belong here; its build-time SSGs do not.
• ../platform-ops-wiki — edge-compute canaries, Strangler Fig rollout and the distributed-systems mindset micro-frontends borrows.
• ../webperf-wiki — the “micro-frontend bundle ≤ 30 kilobytes” fitness function: a byte budget used as an architectural boundary check.
• ../dev-tooling-wiki — Module Federation, bundlers and monorepo tooling as infrastructure; the structures they enable are here.

Index — Frontend Architecture Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox on 2026-08-12 from three sources parked over six weeks. This domain argues more than it measures — record what each source rests on (a migration the author ran, a codebase they shipped, or reasoning alone), and keep the tier honest.

DefinedTerm (concepts / patterns)

• application-architecture — the umbrella: how a client-facing application is divided into parts and who decides the division — the team, the organization, or the framework; the axes are grain, state ownership, where composition happens, what is duplicated on purpose · domain
• micro-frontends — coarse-grained, self-contained, independently deployed units, one team each; defined against the component (“when you optimize for reusability, you create coupling”), and the decisions it forces: vertical/horizontal split, shell vs composer, routing altitude, event emitters over global state · architecture-pattern
• feature-first-structure — capability at the top level with layers nested inside; features own their state, constructor injection over service locators, and the invariant that business rules must not depend on HTTP or serialization · architecture-pattern
• app-shell — the thin long-lived host owning configuration, authorization, composition and routing; the spec is stability — “an application shell that doesn’t change very often after one year” · mechanism
• boilerplate — the starter template as an architecture artifact: a dozen decisions arriving as a bundle, inspectable but unexplained; the class where the deciding party is absent · artifact-class

SoftwareApplication

• wasp — declarative full-stack framework with a compiler: main.wasp.ts generates front-end, back-end and deployment, so the structure is not the author’s to arrange. 18.7k★, v0.24.0, beta; React + TanStack Query / Node + Express / Prisma only · source · T1 · github.com

SoftwareSourceCode (sources)

• open-saas — wasp-lang’s MIT SaaS boilerplate, 15.3k★/1.8k forks/101 open issues (re-verified 2026-08-12): auth (5 providers), payments (Stripe/Polar.sh/Lemon Squeezy), jobs, ShadCN admin, S3, email, analytics, Playwright, Astro Starlight docs, Railway/Fly.io deploy — plus an AGENTS.md/skills/Claude Code plugin surface · source · T1 · github.com

PresentationDigitalDocument (sources)

• micro-frontends-migration — Luca Mezzalira (AWS), QCon San Francisco 2025 via InfoQ, from hundreds of migrations: the component/micro-frontend distinction, the six-step framework, Strangler-Fig rollout on edge compute with rollback by configuration (3 deploys a month → 25 a day per team), “duplication is far cheaper than the wrong abstraction,” and the socio-technical claim · source · T2 · infoq.com

Article (sources)

• flutter-large-app-structure — Ethiel ADIASSA, freeCodeCamp, 23 June 2026: feature-first layout, three layers per feature, feature-level state ownership, constructor DI. “Large applications rarely fail because they lack patterns. They fail because ownership boundaries become unclear.” Cites no study, case or measurement · source · T3 · freecodecamp.org

Person (entities)

• luca-mezzalira — Principal Solutions Architect at aws; the spoke’s only source of figures from work actually done, and the standing caution that his employer sells the edge compute his safest technique runs on

EducationalOrganization (entities)

• freecodecamp — non-profit learning platform; publisher of contributed practitioner articles, which is the genre flutter-large-app-structure belongs to

Synthesis

• synthesis — one question (who decides an application’s structure), three answers, and a domain that argues more than it measures