Data Fetching Patterns
Choosing between REST, GraphQL, and real-time data fetching strategies for optimal application performance.
Quick Navigation: REST • GraphQL • Real-time • Optimistic Updates • Comparison
Data Fetching Landscape
How you fetch data significantly impacts your application's performance, developer experience, and user experience. Choose based on your data requirements and use cases.
- REST: Resource-based, widely adopted, simple
- GraphQL: Query language, flexible, single endpoint
- tRPC: End-to-end type safety, no code generation
- Real-time: WebSockets, SSE, Polling for live data
REST API
Representational State Transfer - resource-based architecture using HTTP methods (GET, POST, PUT, DELETE).
Advantages
- ✓Simple & Familiar: Easy to understand, well-documented
- ✓HTTP Caching: Built-in caching with Cache-Control headers
- ✓Stateless: Each request is independent, easy to scale
- ✓Tooling: Excellent browser DevTools, Postman, etc.
Disadvantages
- ✗Over-fetching: Returns all fields even if not needed
- ✗Under-fetching: Multiple requests for related data
- ✗Versioning: Need to manage API versions
- ✗No type safety: Requires separate type definitions
🎯 Best For:
CRUD applications, public APIs, simple data requirements, teams familiar with REST, when HTTP caching is important.
GraphQL
Query language for APIs - clients request exactly the data they need through a single endpoint.
Advantages
- ✓No over/under-fetching: Request exactly what you need
- ✓Single request: Fetch related data in one query
- ✓Strongly typed: Schema provides type safety
- ✓Self-documenting: Introspection for auto-docs
- ✓Subscriptions: Built-in real-time support
Disadvantages
- ✗Complexity: Steeper learning curve
- ✗Caching challenges: No HTTP caching by default
- ✗N+1 queries: Can cause performance issues if not careful
- ✗File uploads: Not natively supported
🎯 Best For:
Complex data requirements, mobile apps (bandwidth sensitive), multiple clients with different needs, rapid iteration on frontend.
Real-time Data Fetching
Polling
Repeatedly fetch data at fixed intervals.
Pros
- ✓ Simple to implement
- ✓ Works with any API
- ✓ No special infrastructure
Cons
- ✗ Wastes resources (unnecessary requests)
- ✗ Delayed updates (depends on interval)
- ✗ Battery drain on mobile
🎯 Best For: Low-frequency updates, fallback for WebSocket failures
WebSockets
Persistent bidirectional connection between client and server.
Pros
- ✓ True real-time (instant updates)
- ✓ Bidirectional communication
- ✓ Lower latency than polling
- ✓ Efficient for high-frequency updates
Cons
- ✗ Complex connection management
- ✗ Reconnection logic needed
- ✗ Stateful (harder to scale)
- ✗ Firewall/proxy issues
🎯 Best For: Chat apps, gaming, collaborative editing, live trading
Server-Sent Events (SSE)
Server pushes data to client over HTTP connection.
Pros
- ✓ Simpler than WebSockets
- ✓ Auto-reconnection built-in
- ✓ Works over HTTP (firewall friendly)
- ✓ Less resource intensive
Cons
- ✗ Unidirectional (server → client only)
- ✗ Limited browser connections (6 per domain)
- ✗ No binary data support
🎯 Best For: Notifications, live feeds, stock tickers, progress updates
Optimistic vs Pessimistic Updates
Optimistic Updates
Update UI immediately, assume success, rollback on failure.
🎯 Best For: Likes, comments, todos, cart updates
Pessimistic Updates
Wait for server confirmation before updating UI.
🎯 Best For: Payments, critical data, complex validation
Comparison Table
| Approach | Latency | Complexity | Best Use Case |
|---|---|---|---|
| REST | Medium | Low | CRUD, Public APIs |
| GraphQL | Low (single request) | Medium | Complex data needs |
| Polling | High (interval dependent) | Low | Low-frequency updates |
| WebSockets | Very Low | High | Real-time collaboration |
| SSE | Low | Medium | Live feeds, notifications |
Decision Guide
- 1.Simple CRUD with caching? → REST
- 2.Complex queries, multiple clients? → GraphQL
- 3.Bidirectional real-time? → WebSockets
- 4.Server-push notifications? → SSE
- 5.End-to-end TypeScript? → tRPC