Frontend Architecture
Monorepo: cut CI from the world to a slice
Reading about hub packages is not the same as cutting one out of a live pipeline. Take a monorepo where a one-line change rebuilds everything, find the hub from the graph, fix the boundaries and the cache key, and bring CI from the whole repo down to a slice — with evidence at every step.
Turn the unit’s mental model into a reproducible engineering loop: visualise the dependency graph, measure the affected set and cache hit rate, fix the structural cause (the hub and the boundaries) before the cosmetic ones, wire a correct cache, and verify the CI drop with before/after numbers.
Take a multi-package monorepo whose every PR rebuilds most of the repo (your own, or build a starter of ~12-20 packages with one @acme/utils hub) and bring a typical PR's CI from whole-repo to a small affected slice — without buying bigger runners — proving each step with measurements.
- A before/after table: affected-set size (project count) and CI wall-clock for a leaf change AND a hub-domain change, measured under the same pipeline — not estimated.
- The dependency graph clearly shows the hub gone after the split (re-generated, not assumed), with the former hub's dependents redistributed across narrow leaf packages.
- A demonstration that the boundary rule rejects a forbidden upward import at lint time, with the failing CI log.
- A cache demonstration: a warm-cache run on an unchanged project hits and is restored in well under a second, and a deliberate tsconfig change correctly invalidates the cache (no false hit).
- A one-paragraph write-up naming, for each lever you pulled (split the hub, enforce boundaries, fix the cache key), why it ranked above buying bigger runners or splitting to polyrepo.
- Add a CI gate that prints the affected-set size on every PR and fails (or warns) if a single change affects more than a set fraction of the repo — an early-warning signal that a new hub is forming.
- Inject a false-hit bug: leave a shared config out of the cache inputs, show a stale artifact gets served, then fix the key and prove the same change now invalidates correctly.
- Compare Turborepo and Nx on the same repo for one task: graph generation, affected accuracy, and warm-cache hit time, and write up where each is stronger.
- Add changesets (or equivalent) for versioning the now-narrow shared packages, and contrast the release flow against what the same change would cost as separate polyrepos.
This is the loop you will run on every slow monorepo: visualise the graph first, measure the affected set and hit rate, then fix at the top of the ladder — split the hub and enforce boundaries before you touch hardware, and make the cache key correct before you trust the hit rate. Defend the graph with a boundary rule and an affected-size gate, and verify the CI drop with before/after numbers on the same pipeline. Doing it once on a small repo makes the production version muscle memory.