Data Fetching & API Clients
Want to propose a change, disagree with a placement, or add an interesting new technology? Please reach out to @Damian Szafranek. This Tech Radar is a living document - we keep it useful by updating it together as our projects, tools, and experiences evolve.
Scope
This section covers libraries, techniques, and patterns for fetching data from APIs (REST, GraphQL, etc.), managing server state synchronization (caching, background updates, mutations), handling API request states (loading, error, success), and specific API paradigms we interact with.
Overview
ADOPT
Proven technologies we have high confidence in; our default choices.
HOLD
Not recommended for new work; plan migration from existing uses.
ย
Technologies Breakdown
Fetch API ADOPT
The browser's built-in standard for making HTTP requests. Use for simple, one-off requests where the overhead of a dedicated library or server state management isn't necessary (e.g., simple API calls in utility scripts, basic form submissions). Also serves as the foundation for many higher-level libraries.
Native browser API, requires no external dependencies. Universally available. Sufficient for basic needs, but lacks features like interceptors, automatic transforms, or advanced cancellation found in libraries like Axios or the caching/sync features of React Query/SWR. Adopted as the fundamental baseline.
Axios ADOPT
Recommended HTTP client library when more features than Fetch API are needed, but a full server state management library (like React Query) is not being used or is inappropriate for the specific task. Useful for its interceptors, request/response transformation, and cancellation tokens.
Provides a more convenient and feature-rich API over the native Fetch API (e.g., automatic JSON parsing, interceptors for auth/logging, easier error handling). Widely used and understood. Adopted as the preferred general-purpose HTTP client when advanced features beyond Fetch are required.
React Query (TanStack Query) ADOPT
The standard and strongly recommended library for managing server state (fetching, caching, synchronizing, updating) in React/Next.js applications. Use for virtually all data fetching that populates UI components.
Dramatically simplifies server state management, handling caching, background updates, stale-while-revalidate, mutations, pagination, infinite queries, and more out-of-the-box. Improves performance and user experience significantly. Reduces boilerplate compared to manual state management for fetched data. Strong community, excellent documentation, and actively maintained. Adopted as the default choice for server state.
RESTful APIs ADOPT
Our default API style for both service-to-server and client-to-server communication. Use REST unless a specific requirement points elsewhere, and keep to conventional resource modelling, HTTP verbs and status codes so that clients behave predictably.
REST is already the assumption behind most of what we adopt: Spring Boot and Spring Data JPA on the producing side, Fetch API, Axios and React Query on the consuming side, and REST Assured for testing. That consistency is the main argument for keeping it as the default, because it is the path with the most internal experience and the least integration friction. We would reach for an alternative only with a stated reason, such as gRPC for high-volume internal service-to-service calls, or GraphQL for clients with genuinely graph-shaped data needs, as on openIMIS. Neither displaces REST as the default, so it stays the choice until a project makes the case explicitly.
openapi-typescript & openapi-fetch ADOPT
Worth using where the backend produces a trustworthy OpenAPI specification: generate the types and the client from it rather than hand-writing either. An alternative to Axios that keeps the server's types.
On the LLM platform we delivered in 2026 the specification was the single source of truth, and regeneration produced around twenty-five thousand lines of types with a continuous integration gate failing the build on drift. Three thin wrappers made it pleasant: one to unwrap a response in a query, one to turn an RFC 7807 problem document into a readable message, and one to map validation errors onto form fields. The reason to prefer this over rolling a wrapper around Axios is precisely that a hand-rolled wrapper loses the server's types.
GraphQL TRIAL
Worth using where a project's data is genuinely graph-shaped, and the default when working on openIMIS, which already exposes a GraphQL API. Choose the client deliberately: Apollo Client where its caching earns its weight, urql where something lighter will do.
We have run GraphQL in production for years on openIMIS, a project we support long term, so the paradigm itself is no longer an open question for us. It stays at Trial rather than Adopt because that is a single codebase, and one where the API shape was largely inherited rather than chosen by us. What would move it to Adopt is picking it deliberately on a second project and settling on one client library. Where it does come up, the pattern to reach for is the common one: GraphQL aggregating over REST services rather than replacing them.
tRPC ASSESS
Explore on full-stack TypeScript projects (especially those using Next.js or Node.js backends) where end-to-end type safety between backend and frontend is highly desirable. Evaluate its developer experience, impact on build process, and suitability for team workflow.
Offers automatic end-to-end type safety without code generation, simplifying API integration and reducing runtime errors in full-stack TypeScript applications. Promises significant DX improvements. We are assessing its practical benefits, learning curve, potential limitations, and overall fit for our full-stack development practices compared to traditional REST and GraphQL approaches.
SWR ASSESS
Monitor as a prominent alternative to React Query, particularly noting its development by Vercel and potential optimizations within the Next.js ecosystem. Investigate its specific features (e.g., default revalidation behaviour, hook API) and compare its performance and DX against React Query in specific scenarios via PoCs if warranted.
A popular and capable server state library similar to React Query. Given our adoption of React Query, SWR is placed in Assess. We need to understand if it offers compelling advantages in specific situations or aligns better with potential future framework choices (e.g., deeper Next.js integration) before considering it for Trial or Adopt.
gRPC ASSESS
Weโre moving gRPC out of HOLD and into ASSESS: itโs still not our default API approach, but itโs worth re-evaluating for cases where it genuinely shines. gRPC can be a strong fit for high-throughput, low-latency service-to-service communication, strict contract-first APIs, and polyglot environments where generated clients reduce integration friction. For most external/public integrations we still prefer REST for simplicity and interoperability, but weโll keep gRPC on the radar and use it selectively when the performance/contract benefits clearly outweigh the added operational and tooling complexity.