Skip to content

📡 API Integration

While standard REST is the baseline, SSE is the senior’s secret weapon for “one-way” real-time updates.

  • How it works: A standard HTTP connection that stays open. The server “pushes” data to the client whenever an update occurs.
  • Pros: Uses standard HTTP (easier to scale via load balancers); automatic reconnection; lighter than WebSockets for read-only streams.
  • Best For: Live scoreboards, stock tickers, or notification feeds.

When you need full-duplex communication where both the client and server can talk at any time.

  • The Protocol: Starts as an HTTP request and “upgrades” to a persistent TCP connection (ws://).
  • Senior Challenges:
    • State Management: Every open connection consumes server memory. You must handle “Heartbeats” (Pings/Pongs) to detect dead connections.
    • Scalability: If you have multiple server instances, you need a Pub/Sub (like Redis) to broadcast messages between servers so a user on Server A can talk to a user on Server B.
  • Best For: Chat apps, collaborative editing (Google Docs style), and multiplayer gaming.

GraphQL solves the “Over-fetching” and “Under-fetching” problems of REST.

  • Core Concepts:
    • Queries: Ask for exactly what you need.
    • Mutations: Change data on the server.
    • Subscriptions: Real-time updates (usually implemented via WebSockets).
  • Senior Strategy: Use Fragments to keep your frontend code modular. A component should define the data it needs, and the parent “composes” those fragments into a single query.
  • The Trade-off: GraphQL moves complexity from the API to the Server (Schema design, Resolver optimization). Beware of the N+1 problem in resolvers—use a tool like DataLoader to batch requests.

Modern browsers now support reading response bodies as a ReadableStream.

  • The Use Case: Large datasets or AI responses (like ChatGPT). You don’t want to wait for a 2MB JSON to finish downloading before showing the first line to the user.
  • Implementation: Using ndjson (Newline Delimited JSON), the server sends one object at a time. The frontend processes each “chunk” as it arrives.

Never call fetch or useQuery directly in your UI components with raw URLs.

  • Senior Move: Create an API Client Layer. Your components should call UserService.getProfile(id), which hides whether that data comes from REST, GraphQL, or a local cache. This makes switching protocols or mocking for tests much easier.

Don’t make the user wait for the server to say “Success.”

  • Strategy: When a user clicks “Like,” update the UI immediately. In the background, send the API request. If the request fails, roll back the UI state and show an error. Libraries like TanStack Query make this logic much simpler to manage.
  • Scenario: A WebSocket connection fails.
  • Senior Move: Implement a fallback mechanism. If the socket fails to connect after 3 tries, revert the app to Long Polling or standard REST fetches to ensure the user isn’t stuck.

💡 Seniority Note: Before implementing WebSockets, ask: “Do I actually need real-time, or is a 30-second TTL in the cache enough?” Real-time adds massive complexity to your infrastructure and debugging. Often, a well-tuned Cache-Aside strategy is better for 90% of use cases.


  • [[Backend-API-Design-Best-Practices]]
  • [[Caching-Redis-Distributed-Cache]]
  • [[Frontend-State-Management-Server-State]]