Comparison | React Query vs SWR vs Apollo vs RTK Query

This comparison table strives to be as accurate and as unbiased as possible. If you use any of these libraries and feel the information could be improved, feel free to suggest changes (with notes or evidence of claims) using the "Edit this page on Github" link at the bottom of this page.

Feature/Capability Key:

  • βœ… 1st-class, built-in, and ready to use with no added configuration or code
  • 🟑 Supported, but as an unofficial 3rd party or community library/contribution
  • πŸ”Ά Supported and documented, but requires extra user-code to implement
  • πŸ›‘ Not officially supported or documented.
React QuerySWR (Website)Apollo Client (Website)RTK-Query (Website)
Github Repo / Stars
Platform RequirementsReactReactReact, GraphQLRedux
Their Comparison(none)(none)Comparison
Supported Query SyntaxPromise, REST, GraphQLPromise, REST, GraphQLGraphQLPromise, REST, GraphQL
Supported FrameworksReactReactReact + OthersAny
Supported Query KeysJSONJSONGraphQL QueryJSON
Query Key Change DetectionDeep Compare (Stable Serialization)Shallow CompareDeep Compare (Unstable Serialization)Referential Equality (===)
Query Data Change DetectionDeep Comparison + Structural SharingDeep Compare (via dequal)Deep Compare (Unstable Serialization)Referential Equality (===)
Query Data Memoization LevelQuery + Structural SharingQueryQuery + Entity + Structural SharingQuery
Bundle Size
API DefinitionOn-Use, DeclarativeOn-UseGraphQL SchemaDeclarative
Queriesβœ…βœ…βœ…βœ…
Cachingβœ…βœ…βœ…βœ…
Devtoolsβœ…πŸŸ‘βœ…βœ…
Polling/Intervalsβœ…βœ…βœ…βœ…
Parallel Queriesβœ…βœ…βœ…βœ…
Dependent Queriesβœ…βœ…βœ…βœ…
Paginated Queriesβœ…βœ…βœ…βœ…
Infinite Queriesβœ…βœ…βœ…πŸ›‘
Bi-directional Infinite Queriesβœ…πŸ”ΆπŸ”ΆπŸ›‘
Infinite Query Refetchingβœ…βœ…πŸ›‘πŸ›‘
Lagged Query Data1βœ…πŸ”ΆπŸ›‘βœ…
Selectorsβœ…πŸ›‘βœ…βœ…
Initial Dataβœ…βœ…βœ…βœ…
Scroll Recoveryβœ…βœ…βœ…βœ…
Cache Manipulationβœ…βœ…βœ…βœ…
Outdated Query Dismissalβœ…βœ…βœ…βœ…
Render Batching & Optimization2βœ…πŸ›‘πŸ›‘βœ…
Auto Garbage Collectionβœ…πŸ›‘πŸ›‘βœ…
Mutation Hooksβœ…πŸŸ‘βœ…βœ…
Offline Mutation Supportβœ…πŸ›‘πŸŸ‘πŸ›‘
Prefetching APIsβœ…πŸ”Άβœ…βœ…
Query Cancellationβœ…πŸ›‘πŸ›‘πŸ›‘
Partial Query Matching3βœ…πŸ›‘πŸ›‘βœ…
Stale While Revalidateβœ…βœ…βœ…βœ…
Stale Time Configuration7βœ…πŸ›‘πŸ›‘βœ…
Pre-usage Query/Mutation Configuration4βœ…πŸ›‘πŸ›‘βœ…
Window Focus Refetchingβœ…βœ…πŸ›‘πŸ”Ά
Network Status Refetchingβœ…βœ…βœ…πŸ”Ά
General Cache Dehydration/Rehydrationβœ…πŸ›‘βœ…βœ…
Offline Cachingβœ… (Experimental)πŸ›‘βœ…πŸ”Ά
React Suspense (Experimental)βœ…βœ…πŸ›‘πŸ›‘
Abstracted/Agnostic Coreβœ…πŸ›‘βœ…βœ…
Automatic Refetch after Mutation5πŸ”ΆπŸ”Άβœ…βœ…
Normalized Caching6πŸ›‘πŸ›‘βœ…πŸ›‘

Notes

1 Lagged Query Data - React Query provides a way to continue to see an existing query's data while the next query loads (similar to the same UX that suspense will soon provide natively). This is extremely important when writing pagination UIs or infinite loading UIs where you do not want to show a hard loading state whenever a new query is requested. Other libraries do not have this capability and render a hard loading state for the new query (unless it has been prefetched), while the new query loads.

2 Render Optimization - React Query has excellent rendering performance. It will only re-render your components when a query is updated. For example because it has new data, or to indicate it is fetching. React Query also batches updates together to make sure your application only re-renders once when multiple components are using the same query. If you are only interested in the data or error properties, you can reduce the number of renders even more by setting notifyOnChangeProps to ['data', 'error']. Set notifyOnChangeProps: 'tracked' to automatically track which fields are accessed and only re-render if one of them changes.

3 Partial query matching - Because React Query uses deterministic query key serialization, this allows you to manipulate variable groups of queries without having to know each individual query-key that you want to match, eg. you can refetch every query that starts with todos in its key, regardless of variables, or you can target specific queries with (or without) variables or nested properties, and even use a filter function to only match queries that pass your specific conditions.

4 Pre-usage Query Configuration - This is simply a fancy name for being able to configure how queries and mutations will behave before they are used. For instance, a query can be fully configured with defaults beforehand and when the time comes to use it, only useQuery(key) is necessary, instead of being required to pass the fetcher and/or options with every usage. SWR does have a partial form of this feature by allowing you to pre-configure a default fetcher, but only as a global fetcher, not on a per-query basis and definitely not for mutations.

5 Automatic Refetch after Mutation - For truly automatic refetching to happen after a mutation occurs, a schema is necessary (like the one graphQL provides) along with heuristics that help the library know how to identify individual entities and entities types in that schema.

6 Normalized Caching - React Query, SWR and RTK-Query do not currently support automatic-normalized caching which describes storing entities in a flat architecture to avoid some high-level data duplication.

6 SWR's Immutable Mode - SWR ships with an "immutable" mode that does allow you to only fetch a query once for the life of the cache, but it still does not have the concept of stale-time or conditional auto-revalidation

Was this page helpful?

Resources

Subscribe to our newsletter

The latest TanStack news, articles, and resources, sent to your inbox.

    I won't send you spam.

    Unsubscribe at any time.

    Β© 2020 Tanner Linsley. All rights reserved.