Frontend Architecture
Monorepo: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — the dependency graph, affected detection, the remote-cache key, module boundaries, and the monorepo-vs-polyrepo tradeoff — without looking back at the lesson.
- 01Why is the dependency graph, not the folder layout, what makes a monorepo fast or slow?
- 02What does affected detection compute, and how does it differ from build-everything?
- 03What goes into a remote-cache key, and what are the two failure modes of getting it wrong?
- 04How do affected scoping and remote caching divide the work, and why do you need both?
- 05Why does a single 'shared utils' package wreck the affected graph, and what is the structural fix?
- 06Describe the monorepo-vs-polyrepo tradeoff honestly. When do you pick each?
If you could reconstruct each answer from memory, you hold the unit’s spine: the dependency graph sets ordering and blast radius, affected detection narrows each PR to changed projects plus dependents, the cache key turns most of those into instant hits (with false hits and false misses as the two ways to get the key wrong), enforced module boundaries keep a hub from forming, and the monorepo-vs-polyrepo call comes down to whether your code is coupled enough to share a graph.