Client-Server Systems, APIs, and Web Application Architecture
Applications as Distributed Systems
Architectural Layers
A web application is often a distributed system spanning browser, edge, application server, cache, database, and third-party services. Design choices about where to render, validate, cache, and synchronize state have profound implications for latency, resilience, and maintainability. Modern architectures blend server-side rendering, client-side hydration, API-first development, and event-driven backends.
API Design Terms
State Synchronization and Consistency
Distributed web apps must reconcile local UI state with server state. This introduces consistency trade-offs: optimistic updates improve responsiveness but risk divergence; pessimistic flows improve correctness but may feel slower. Research and engineering practice increasingly focus on eventual consistency, conflict resolution, offline-first interactions, and collaborative editing.
SSR, CSR, and the Hybrid Spectrum
The distinction between server-side rendering and client-side rendering is no longer binary. Contemporary systems often use selective hydration, streaming responses, islands architecture, or partial prerendering.
What is a common benefit of server-side rendering?
Server-side rendering can improve time-to-content and help search engines or low-powered devices access meaningful HTML sooner.
Correct answer: Faster initial content delivery and better crawlability
What does idempotence mean in API design?
Idempotent operations are useful for retries and reliability in distributed systems.
Correct answer: Repeating the same request has the same effect as making it once
Which technique allows a client to request only the data it needs?
GraphQL enables flexible client-specified queries for precisely shaped responses.
Correct answer: GraphQL
Rendering Strategies
CSR
- Rich client interactivity
- More JavaScript at startup
- Can delay initial content for low-end devices
SSR
- HTML available earlier
- Potentially better initial perception
- Requires hydration and server infrastructure
Choosing an Application Architecture
-
1
Step 1: Identify latency, SEO, and interactivity requirements.
-
2
Step 2: Decide where each piece of state should live.
-
3
Step 3: Choose a rendering model and data-fetching strategy.
-
4
Step 4: Define cache boundaries and invalidation rules.
-
5
Step 5: Instrument the system to detect failures and regressions.