react-brain
Browse decisions
React & language foundations 3App architecture 9UI 12Platform & native 9Build, test, observe, secure 6AI in React apps 3stack composerdecision recordscensusstaleness bencharchitecturechangelogmethodologyroadmap

entriesapp-architecture · verified 2026-07-09 · react + react-native

Networking & HTTP client layer

draftedconfidence: mediumthis tier holds 50% on the public scorecard (3/19 graded · 0 overturned) →

related decisions: data · ai-ui · p2p

re-verified 2× — 2026-07-13 · 2026-07-09 · changelog

recommendation

Use fetch — on Expo SDK 56+ you are already on expo/fetch globally. The bigger win in most apps is the CACHE layer above it (TanStack Query, RB-E-DATA), not the client. Reach for react-native-nitro-fetch only when the network layer is a MEASURED hot path (cold-start requests, media, HTTP/3 backends) or you need prefetch/worklet parsing.

  • team already on axios → keep it; interceptor ergonomics are real and migration buys little
  • streaming responses (AI/chat tokens, SSE-style) → expo/fetch or nitro-fetch (streaming + TextDecoder) — see RB-E-AI-UI
  • measured network hot path / prefetch-before-navigation / HTTP-3 backend → react-native-nitro-fetch (drop-in)
  • server-state caching, retries, invalidation → that's TanStack Query territory (RB-E-DATA), regardless of client
  • P2P / Holepunch app → there may be no HTTP layer at all; transport is Hyperswarm streams (RB-E-P2P)

Options & tradeoffs

the field considered — and why each one isn’t the default here

optiontradeoffevidence
fetch (built-in)the default on both platforms — RN's WHATWG polyfill over native networking, the browser's native fetch on web; fine for most apps78k/wk · ships in 1/34
expo/fetchWinterTC-compliant fetch with streaming — installed as the GLOBAL fetch since Expo SDK 56 (no import needed); the modern managed default
react-native-nitro-fetch (Margelo)drop-in native fetch on Cronet (Android) / URLSession (iOS) — HTTP/1-2-3+QUIC, Brotli, disk cache, prefetch-before-navigation, worklet parsing off the JS thread; measured ~1.3x vs built-in; v1.5, ~900★, RN 0.75+78k/wk · ships in 1/34
axiosthe ubiquitous promise client (interceptors, defaults, wide team familiarity); runs over XHR in RN — no reason to churn OFF it, little reason to start ON it for new work90.6M/wk · ships in 7/34
ky / ofetchsmall fetch wrappers (retries, hooks, typed convenience) — web-leaning; ky 2.x, ofetch (unjs)21.5M/wk

evidence: npm weekly downloads (signals snapshot) · “ships in n/D” = adoption across the production-app census, honest denominators

npm weekly downloads (from the corpus's last signals run): axios 90.6M · react-native-nitro-fetch 78k · ky 6.8M · ofetch 21.5M

Verified notes

NEW entry (2026-07-09): the fetch-layer choice had no home — flagged as a gap candidate in the Native Weekly first-harvest (nitro-fetch featured twice; SDK 56 made expo/fetch the global default, verified vs the SDK 56 changelog) and promoted on the user's call. The durable axis: RN's built-in fetch is a JS polyfill over native networking; expo/fetch standardizes it (WinterTC + streaming); nitro-fetch swaps the ENGINE (Cronet/URLSession, HTTP/3) behind the same API. Client choice is low-stakes compared to cache design — hence the DATA cross-refs. nitro-fetch facts verified vs its repo (benchmarks are vendor-run; ~23% on their harness).

Canonical reading

Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.

react-native-nitro-fetch — architecture & benchmarksMargelo

The README doubles as the layer's best explainer: what actually backs fetch on each platform (Cronet vs URLSession), what HTTP/3+QUIC/Brotli/disk-cache buy you, prefetch-before-navigation, and worklet-side parsing — with their benchmark methodology. Read it to understand the layer even if you keep built-in fetch.

Sources

Related in app-architecture: state · data · p2p · nav · meta-frameworks · forms · crossplatform · desktop