An API layer with retry, backoff and shared in-flight requests
Two components need the same user, but the server sees one request that fails, one retry after 100 ms, and success. Components never call fetch; the API layer owns retries and errors.
Every frontend design is assembled from the same blocks: a rendering choice, a component tree with state in the right places, a server cache next to a small client store, routes split into chunks, one API layer, a loading and error strategy, a design system and monitoring.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Add a timeout to the API layer example: if fakeFetch takes longer than 50 ms, treat it as a failure with status 0 and retry.
Add a CartBadge-style component to the four-kinds example that shows the current sort from the URL.
Explain it without notes
How do you choose between CSR, SSR, SSG and streaming for a route?
What's the difference between a server cache and a client store, and why shouldn't server data live in Redux?
What belongs in a frontend API layer?
Describe a loading and error strategy for a page with several independent widgets.
Preview
Console
Nothing logged yet.Expected console output
GET /api/user/1 attempt 1 -> 503
GET /api/user/1 attempt 2 -> 200
server calls: 2