Skip to content
intermediatePhase 44 · Web Architecture

Client

Understand client architectures: web, mobile, and desktop applications.

30m
0 problems
Topic Progress0%

Client Types

Clients are the interfaces through which users interact with your system.

Client Ecosystem

Clients
├── Web Browsers
│   ├── Chrome, Firefox, Safari
│   └── Desktop and Mobile
├── Mobile Apps
│   ├── iOS (Swift/SwiftUI)
│   ├── Android (Kotlin/XML)
│   └── Cross-platform (React Native, Flutter)
├── Desktop Apps
│   ├── Electron (Web-based)
│   ├── Native (C++, Java)
│   └── .NET (WPF, WinForms)
├── API Consumers
│   ├── Other services
│   ├── IoT devices
│   └── Third-party integrations
└── Command Line
    └── CLI tools and scripts

Client Comparison

Client Pros Cons Use Case
Web Universal, no install Limited offline, slower Public-facing apps
Mobile Native features, offline Platform-specific, app store Consumer apps
Desktop Full access, fast No cross-platform Power users
API Machine-readable No UI Integrations

Client-Side Rendering Approaches

1. Server-Side Rendering (SSR)
   Server renders HTML → Client displays
   + Fast initial load, SEO friendly
   - Slower interactivity

2. Client-Side Rendering (CSR)
   Server sends JS → Client renders
   + Rich interactivity
   - Slower initial load, SEO challenges

3. Static Site Generation (SSG)
   Build time generates HTML
   + Very fast, CDN-friendly
   - Dynamic content harder

4. Incremental Static Regeneration (ISR)
   Static + periodic revalidation
   + Best of both worlds
   - Complex caching

Client Architecture

Modern client applications have their own architecture considerations.

Component Architecture

┌─────────────────────────────────────┐
│              Client App             │
├─────────────────────────────────────┤
│  Presentation Layer                 │
│  ├── Components (UI elements)       │
│  ├── Pages (routes)                 │
│  └── Layouts (structure)            │
├─────────────────────────────────────┤
│  State Management                   │
│  ├── Local state (component)        │
│  ├── Global state (app-wide)        │
│  └── Server state (API data)        │
├─────────────────────────────────────┤
│  Data Layer                         │
│  ├── API client (HTTP)              │
│  ├── Cache (local storage)          │
│  └── WebSocket (real-time)          │
└─────────────────────────────────────┘

Client State Management

Type Storage Use Case
Component State Memory UI-specific data
Global State Memory App-wide data
Server Cache Memory/Disk API responses
Persistent LocalStorage/IndexedDB User preferences

Client-Side Performance

Performance Metrics:
- First Contentful Paint (FCP): < 1.8s
- Largest Contentful Paint (LCP): < 2.5s
- First Input Delay (FID): < 100ms
- Cumulative Layout Shift (CLS): < 0.1
- Time to Interactive (TTI): < 3.8s

Optimization:
1. Code splitting
2. Lazy loading
3. Image optimization
4. Bundle size reduction
5. Caching strategies

Client Security

Security Considerations:
- XSS (Cross-Site Scripting)
  → Content Security Policy, input sanitization
- CSRF (Cross-Site Request Forgery)
  → CSRF tokens, SameSite cookies
- Clickjacking
  → X-Frame-Options header
- Sensitive data
  → Never store in localStorage

Client-Server Communication

How clients and servers communicate affects performance and user experience.

Communication Patterns

1. Request-Response (HTTP)
Client ──Request──→ Server
Client ←──Response── Server

2. Server-Sent Events (SSE)
Client ──Request──→ Server
Client ←──Stream── Server (one-way)

3. WebSocket
Client ←──→ Server (bidirectional)

4. Long Polling
Client ──Request──→ Server
Server (waits) → Response (when data available)

When to Use Each

Pattern Latency Use Case
HTTP Higher CRUD operations
SSE Lower Live feeds, notifications
WebSocket Lowest Chat, gaming, collaboration
Long Polling Medium Fallback when WS blocked

HTTP Request Flow

Client                          Server
  │                               │
  │──── GET /api/users ──────────→│
  │                               │
  │←──── 200 OK + JSON ──────────│
  │                               │
  │──── POST /api/users ─────────→│
  │     (body: {name: "John"})     │
  │                               │
  │←──── 201 Created ────────────│

Caching at Client Level

Cache Hierarchy:

1. Browser Cache
   - HTTP headers (Cache-Control, ETag)
   - Service Worker cache

2. Application Cache
   - In-memory cache
   - IndexedDB

3. CDN Cache
   - Edge servers
   - Geographic distribution

Cache-Control Headers:
Cache-Control: max-age=3600  (cache for 1 hour)
Cache-Control: no-cache      (validate with server)
Cache-Control: no-store      (never cache)
ETag: "abc123"               (version identifier)

Practice Problems

0/3solved
Design Client System

Design a scalable Client system. Cover high-level architecture, data model, and API design.

Solution
// Complete system design:
// - Functional + Non-functional requirements
// - Capacity estimation
// - Data model (SQL/NoSQL choice)
// - API endpoints
// - Component architecture
// - Scaling strategy
// - Monitoring & reliability
Client Scaling

How would you scale Client to handle 10x the current load? Identify bottlenecks and solutions.

Solution
// Scaling approach:
// 1. Load balancing
// 2. Database sharding/replication
// 3. Cache layer (Redis)
// 4. CDN for static assets
// 5. Async processing (queues)
// 6. Microservices decomposition
Client Failure Modes

Analyze potential failure modes for Client and design mitigation strategies.

Solution
// Failure mitigation:
// 1. Redundancy (multi-AZ)
// 2. Circuit breakers
// 3. Retry with backoff
// 4. Dead letter queues
// 5. Health checks
// 6. Graceful degradation

Quiz

1. What is the main advantage of Server-Side Rendering (SSR)?

Question 1 options

2. When should you use WebSockets instead of HTTP?

Question 2 options

3. What is Cumulative Layout Shift (CLS)?

Question 3 options

4. What is the purpose of Code Splitting?

Question 4 options

Flashcards

Question

What are the main client types?

Click to reveal answer

Answer

Web browsers (Chrome, Safari), Mobile apps (iOS, Android), Desktop apps (Electron), API consumers (services, IoT), and CLI tools.

Question

What is the difference between SSR and CSR?

Click to reveal answer

Answer

SSR (Server-Side Rendering) renders HTML on the server for fast initial load. CSR (Client-Side Rendering) sends JavaScript and renders on the client for rich interactivity.

Question

When should you use WebSockets?

Click to reveal answer

Answer

For real-time bidirectional communication: chat, gaming, collaboration, live feeds. Provides lower latency than HTTP for persistent connections.

Question

What are Core Web Vitals?

Click to reveal answer

Answer

LCP (Largest Contentful Paint < 2.5s), FID (First Input Delay < 100ms), CLS (Cumulative Layout Shift < 0.1). Google's metrics for user experience.

Question

What is Client?

Click to reveal answer

Answer

Client is a key concept in system design.

Revision Notes

Key Takeaways

  • 1.Choose client type based on user needs and platform requirements
  • 2.SSR for fast initial load, CSR for rich interactivity
  • 3.WebSockets for real-time bidirectional communication
  • 4.Client-side performance metrics (Core Web Vitals) are critical
  • 5.Security must be considered at the client level

Interview Tips

  • •Discuss client requirements before choosing rendering approach
  • •Consider SEO requirements for public-facing web apps
  • •Mention Core Web Vitals when discussing performance
  • •Choose communication pattern based on real-time needs

Cheat Sheet

Client - Cheat Sheet

Client Types:

  • Web: Universal, no install
  • Mobile: Native features, offline
  • Desktop: Full access, fast
  • API: Machine-readable

Rendering Approaches:

Approach Pros Cons
SSR Fast initial load, SEO Slower interactivity
CSR Rich interactivity Slower initial load
SSG Very fast, CDN Dynamic content harder

Communication Patterns:

  • HTTP: CRUD operations
  • SSE: One-way streaming
  • WebSocket: Bidirectional real-time

Core Web Vitals:

  • LCP < 2.5s
  • FID < 100ms
  • CLS < 0.1