A3.4 · Thin but robust · dive 2
What robust adds
Thin sets the size of a slice; robust sets the bar it has to clear — seven concrete properties, named once in the F6 roadmap.
A thin thread becomes a shippable rung only when it holds the seven “thin but robust for the web” properties: over the facade, harnessed, verified and safe, rendered in the system, honest real-time, supervised, always live. Score a slice against them on the right; the verdict reads robust only at seven of seven.
Score a slice against the seven · pick one
Seven properties, named once
The F6 roadmap collects what makes a thin slice production-grade into one section, “thin but robust for the web”, and each property names a concrete move a rung makes — not a feeling, not a code review note, but a checkable fact:
- over the facade
- Every controller, LiveView, and template calls only
Portaland renders only the closed%Portal.Error{}set; the web invents no domain logic and no new error vocabulary. - harnessed
- Controllers via
ConnTest, LiveViews viaLiveViewTest, enrollment against the in-memory adapter, so the suite is fast and needs no live browser. - verified, safe
- Verified routes (a path typo fails to compile), escaped interpolation, declared component attributes.
- in the system
- Dynamic pages emitted through a shared root layout and a single token stylesheet, the tokens declared once.
- honest real-time
- Broadcasts fire only after a successful write, so clients only ever learn of facts.
- supervised
- New runtime pieces (endpoint, PubSub, Presence) are supervised children; the engine's crash isolation is untouched.
- always live
- Every rung leaves the node booting clean and serving —
GET /healthanswers200and the route renders (its own dive, A3.4.3).
The first property is the master invariant: the web layer calls only the
Portal facade and renders only the closed %Portal.Error{}
set. The other six hang off it — which is what makes every rung robust without re-deciding the
architecture.
Drop one property, watch what breaks
The seven are not decoration; each prevents a specific failure. The quickest way to see that is to take a slice that holds all seven and drop one — the slice falls from robust to flimsy, and the readout names the failure that property was preventing.
The two figures teach different moves: the hero scores a slice against all seven at once; this one holds a 7/7 slice fixed and removes one property to show the specific regression it lets back in.
Drop a property from a 7/7 slice · pick one
Each of the seven prevents a named failure — drop one and the slice falls from robust to flimsy.
What robust adds, on the Portal
On the Portal, a slice that “renders the catalog” is thin and vertical, but it is not a rung until
it holds all seven. It must be over the facade (every controller calls only the
Portal facade), harnessed (a ConnTest GET smoke), verified
and safe (a verified route, escaped
interpolation), rendered in the system (the shared layout), supervised, and always live. Strip a property and
the slice regresses: drop “honest real-time” and a client can learn of a fact that never happened;
drop “supervised” and one crash takes the node down.
This is why robust is a checklist, not a judgement call. The seven properties are the same on every rung, so a new rung clears the same bar without re-arguing what quality means — and the Author building it has a fixed, gradeable definition to build to.
# The seven thin-but-robust-for-the-web properties — a slice is robust at 7/7. properties = [ :over_the_facade, # == the master invariant :harnessed, # a fast test, no live browser :verified_and_safe, # verified routes, escaped output :rendered_in_the_system, # shared layout + token stylesheet :honest_real_time, # broadcast only after a write :supervised, # supervised children, crash isolation kept :always_live # boots clean, GET /health → 200, route renders ] held = 7 robust? = held == 7 # anything below 7 is flimsy
Robust is the bar a thin slice clears: over the facade, harnessed, verified and safe, rendered in the system, honest real-time, supervised, always live — seven concrete moves, not a feeling.
The first property is the master invariant — the web layer calls only the
Portal facade and renders only the closed %Portal.Error{}
set — and the other six hang off it, so every F6 rung is robust without re-deciding the architecture.
Thin is the slice; robust is the seven properties it holds — and the first of them is the master invariant.
Recap — seven checkable moves
Robust is not a feeling about a slice; it is seven checkable properties from the F6 roadmap — over the facade, harnessed, verified and safe, rendered in the system, honest real-time, supervised, always live. A thin thread is a rung only at seven of seven; drop one and it falls to flimsy with a named failure. The first property is the master invariant, and it carries the other six. The next dive isolates the strictest property on its own: always live.
Next in A3.4: A3.4.3 · Always live — the liveness criterion, and why a red rung is a regression, not a rung.
References
The production-quality sources behind the seven properties, and where they connect in the course.
Sources
- Humble & Farley — Continuous Delivery — every increment tested, gated, and releasable; quality built in, not inspected in.
- Beck, K. — Extreme Programming Explained — test-first and continuous integration as the bar a small release clears.
- Hunt & Thomas — The Pragmatic Programmer — orthogonality and design by contract behind the facade boundary.
Related in this course
- A3.4 · Thin but robust — the module hub.
- A3.4.1 · Thin, not shallow — the previous dive.
- A3.4.3 · Always live — the next dive.
- A1.05 · Correct by definition — the harness property, proven.
- A1.02 · Contracts — the over-the-facade property as a contract.
- F6 · The Portal on the web (Phoenix) — where the framework implements the seven properties.