Portfolio ↗

UI Monorepo Strategy

One repository for many front ends, and the build graph that makes it viable.

4Questions
8Flashcards
2Terms
Drill this topic All of Frontend & Experience Architecture
Questions

4 to work through

  1. intermediate Multiple choice

    Ten applications consume one design system and upgrades keep stalling because each app schedules them separately. Which release and consumption model keeps the total upgrade cost bounded as applications are added?

    2 min answer
  2. intermediate

    Ten frontend teams share a design system. Monorepo or separate repositories?

    1 min answer
  3. advanced

    Eleven frontend repositories consume a design system published to a private registry. The median application is four minor versions behind and a token change takes seven weeks to reach every application. The team wants one monorepo. Give the sequence under live weekly releases, where state can diverge, the point of no return, and how long it really takes.

    3 min answer
  4. advanced Multiple choice

    Many frontend applications share components, tooling and types. Monorepo or separate repositories?

    1 min answer
Terminology

2 terms in this topic

concept

Build Graph Scoping

Determining which packages a change actually affects, so a monorepo builds and tests a subset rather than everything on every commit.

 practice

UI Monorepo Strategy

Whether frontend code lives in one repository or many — a trade between atomic change and independent release.
Frontend & Experience Architecture

Neighbouring topics

Frontend & Experience Architecture

General material on architecting the surface the user actually touches.

4 quiz 8 cards 2 terms

Rendering Strategies

Client, server, static and incremental rendering, and what each costs on first paint.

5 quiz 10 cards 3 terms

Edge Rendering

Running the render close to the user, and the personalisation and cache trade it implies.

5 quiz 8 cards 3 terms

Hydration Cost

The gap between visible and interactive, and the JavaScript that closes it.

5 quiz 11 cards 4 terms

Micro-Frontends

Independent deployment of UI slices, and the shared runtime that undermines it.

5 quiz 9 cards 3 terms

Module Federation

Loading code from another build at runtime, with versioning and failure to think about.

4 quiz 9 cards 4 terms

Design Systems

Components as a versioned internal product, with adoption and deprecation like any API.

5 quiz 8 cards 2 terms

Component Contracts

Props, slots and events as an interface, and the breaking change hidden in a style.

4 quiz 9 cards 3 terms

Client State Architecture

Server state, UI state and derived state, and why conflating them causes most bugs.

4 quiz 10 cards 3 terms

Client Caching & Data Layer

Stale-while-revalidate, invalidation and optimistic updates on the client.

6 quiz 10 cards 4 terms

BFF for Experience

One backend per experience, shaped by the screen rather than by the domain.

4 quiz 8 cards 2 terms

API Shapes for UI

REST, GraphQL and RPC judged by over-fetching, round trips and client coupling.

4 quiz 11 cards 3 terms

Web Performance Budgets

A number a build can fail against, rather than a performance sprint once a year.

3 quiz 8 cards 5 terms

Core Web Vitals

LCP, INP and CLS — what they measure, and the architecture that moves them.

5 quiz 10 cards 3 terms

Accessibility Architecture

Semantics, focus management and announcements designed in rather than audited in.

6 quiz 6 cards 3 terms

Internationalisation

Locale, direction, pluralisation and dates as structural concerns, not string tables.

5 quiz 11 cards 4 terms

Client Feature Flags

Flag evaluation on a device you do not control, and the flicker and staleness it brings.

4 quiz 10 cards 4 terms

Real User Monitoring

Field data from real devices and networks, against the synthetic run that looked fine.

4 quiz 10 cards 5 terms

Frontend Security

CSP, XSS, CSRF, token storage, and the trust boundary that ends at the browser.

5 quiz 9 cards 4 terms