When to Avoid SWR in React

While SWR (Stale-While-Revalidate) is an excellent library for data fetching in React, it is not the ideal tool for every project. This article outlines the specific scenarios where you should avoid using SWR, such as when dealing with complex non-GET operations, advanced GraphQL architectures, offline-first requirements, or server-centric frameworks like Next.js App Router.

1. Your Application Relies Heavily on GraphQL

SWR can fetch GraphQL data using libraries like graphql-request, but it lacks the advanced features required for complex GraphQL APIs. If your application relies on normalized caching, fragment colocation, or schema-based optimizations, dedicated GraphQL clients like Apollo Client or Relay are much better suited than SWR.

2. You Need Complex Mutation Workflows

SWR is designed primarily for fetching and caching data (HTTP GET requests). While it does offer a mutate function, managing complex write operations (POST, PUT, DELETE) with intricate client-side rollbacks, optimistic updates, and multi-query invalidations can quickly become verbose and difficult to maintain compared to using TanStack Query (React Query).

3. You Are Building an Offline-First Application

SWR provides basic offline support, but it is not built to handle the complex synchronization and conflict-resolution requirements of a true offline-first application. If your application needs to queue local changes and sync them with a database once a connection is re-established, you should look toward specialized databases and libraries like WatermelonDB, RxDB, or TanStack Query’s persistent offline plug-ins.

4. You Are Using Next.js Server Components

If you are building a modern Next.js application using the App Router, the framework’s native fetch implementation already includes built-in caching, revalidation, and data-fetching capabilities at the server level. Introducing SWR in this environment is often redundant, as it shifts data fetching back to the client side, increasing bundle size and delaying the initial page load.

5. You Require Normalized Caching

SWR uses a document-based cache, meaning it stores data under unique keys (like URLs). If you fetch the same user object from two different endpoints, SWR will store them separately. If one is updated, the other remains stale. If your app requires a normalized cache where updates to a specific entity automatically propagate across all queries containing that entity, SWR is not the right choice.