frontend / README.md

APIs & Data Fetching — Senior Interview Prep

1 min read index source

APIs & Data Fetching — Senior Interview Prep

The other half of a fullstack interview: how the client consumes APIs. Choice of protocol, request lifecycle, caching layer, optimistic UX, real-time channels, and the failure modes that only show up under flaky networks and concurrent users.

Files

# Topic
01 REST vs GraphQL vs tRPC — when each wins
02 TanStack Query — cache keys, invalidation, prefetch
03 Optimistic updates and rollback
04 Pagination — offset vs cursor and infinite queries
05 AbortController, request dedup, race conditions
06 Retries, backoff, and idempotency
07 WebSockets — integration patterns and reconnection
08 Server-Sent Events vs WebSockets vs long polling
09 File uploads — multipart, presigned S3, chunked, resumable

What a senior is expected to frame

  • Server state ≠ client state. Server-fetched data has a cache, a freshness model, a refetch schedule, and rules for when it’s stale. Treat it differently from local UI state — most “Redux complexity” disappears once you separate the two. See ../07_state_managers/ for the state-management side.
  • Failure is the design. Network requests fail. Servers throw 5xx. Users double-click. Tabs sleep mid-request. The interview answer always names: timeout, retry policy (and which methods are retryable — see ../../backend/12_protocols/http/03_http_semantics_and_caching.md), idempotency, abort, and the UX during each.
  • Latency budget shapes architecture. A typeahead has a different budget than a checkout. Pagination strategy, debounce, prefetching, optimistic UX — all flow from the budget.

Cross-references