Frontend Architecture
Monorepo: multiple-choice review
Crux Multiple-choice synthesis across the monorepo unit: dependency graph, affected detection, remote-cache keys, module boundaries, and the monorepo-vs-polyrepo tradeoff.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make on a real CI pipeline — not a definition to recite, but a tradeoff to weigh when the merge queue is backing up.
Goal
Confirm you can connect the dependency graph, affected detection, remote caching, and module boundaries into one decision: build what changed and its dependents, cache the rest, and never let a hub package make every PR rebuild the world.
Quiz
Completed
A one-line copy fix to a marketing page sits in CI for 41 minutes; all 38 projects rebuilt. The import resolved through @acme/utils, which every app and library depends on. What is the actual cause?
Heads-up Caching cannot save a hub. A change to utils produces a new input hash for every dependent, so every dependent is a legitimate cache miss. The miss is correct; the graph is wrong.
Heads-up Bigger runners build the same 38 projects faster, but you are still building 38 for a one-line change — paying with repo size, not change size. The 41-minute job returns as the repo grows.
Heads-up It detected the change correctly. The unit of affected is the project, and walking dependents from a hub legitimately reaches the whole repo. The fix is to split the hub, not to scope tighter.
Quiz
Completed
What does affected (Nx) / filtered (Turborepo) actually compute for a PR, before caching is considered?
Heads-up That is build-everything. Affected exists precisely to skip untouched projects; running them all in parallel still scales with repo size, not change size.
Heads-up Files are not the unit — projects are — and dependents must be included: a change to a library can break the apps that import it, so they must be retested too.
Heads-up That is the cache's separate job. Affected decides which projects are candidates; the cache then decides which candidates can be skipped because their output already exists.
Quiz
Completed
A PR served a stale build from the remote cache and shipped a bug, even though hit rate was high. Most likely cause?
Heads-up Eviction causes a miss and a rebuild, not a stale-but-served artifact. A stale hit means the hash matched when it should not have — a missing input in the key.
Heads-up If affected skipped it, nothing was served for that project at all. A stale served artifact means a task ran, checked the cache, hit, and got the wrong entry — a key problem.
Heads-up A high hit rate is not the bug; an incorrect key is. A correct key gives correct hits. The goal is exactly a high hit rate with a key that captures every real input.
Quiz
Completed
Why does a concurrent dev forgetting to add a glob to a task's inputs cause CI to silently slow down rather than break?
Heads-up That is the opposite failure. Too FEW real inputs causes false hits (stale artifacts); too MANY or volatile inputs causes false misses (no reuse). This question is the false-miss side.
Heads-up Input globs feed the cache key, not task ordering. Ordering comes from the dependency graph (dependsOn / targetDependencies), and is unaffected by a noisy input glob.
Heads-up Affected is computed from the git diff against base, not from cache-key inputs. A volatile input hurts cache hit rate, not the size of the affected set.
Quiz
Completed
A team enforces Nx tags so feature → ui → util is the only allowed direction. A dev adds an import from a util library into a feature library and CI fails at lint. Why is this the intended behaviour, not friction?
Heads-up Unenforced boundaries are how the @acme/utils hub forms in the first place. The lint failure is cheap; an everything-depends-on-everything graph is the 41-minute CI bill the unit opens with.
Heads-up enforce-module-boundaries is about graph shape and blast radius, not formatting. It governs which projects may depend on which, which directly controls affected scope and cache invalidation.
Heads-up The type checker resolves the import fine; that is the problem. The boundary rule catches an architecturally bad edge the compiler is happy with — a structural concern, not a type error.
Quiz
Completed
A team of four independent product squads shares almost no code and communicates only over HTTP APIs. They are weighing monorepo vs polyrepo. Which framing is correct?
Heads-up Monorepo speed comes from affected scoping and caching over a SHARED graph. With near-zero shared code, each polyrepo is already trivially fast and independent; the monorepo tooling overhead earns nothing.
Heads-up Polyrepo trades the CI problem for a coordination one: any shared code travels through a registry with version bumps and lockstep PRs. It is the right trade here only because they share almost nothing.
Heads-up It is about coupling, not size. The deciding question is whether packages share code and change together (favours monorepo) or are truly independent and talk only over APIs (favours polyrepo).
Recap
The through-line across the unit is one pipeline: the dependency graph sets ordering and blast radius, affected detection narrows each PR to the changed projects plus their dependents, remote caching turns most of those into instant hits — and the cache key is the whole game, where a missing input is a dangerous false hit and a volatile one is a wasteful false miss. None of it survives a bad graph, so enforced module boundaries (Nx tags, the enforce-module-boundaries rule, package exports) keep a hub from forming. And the monorepo-vs-polyrepo call is about coupling: shared code that changes together favours the monorepo; truly independent teams favour polyrepo.