2021-05-17
1661
#apollo
Alec Brunelle
49219
May 17, 2021 ⋅ 5 min read

Why I (finally) switched to urql from Apollo Client

Alec Brunelle Alec is a web developer who loves to work in all areas of the stack. Currently hacking on GraphQL services at Unity Technologies.

Recent posts:

Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Learn how to effectively debug with Chrome DevTools MCP server, which provides AI agents access to Chrome DevTools directly inside your favorite code editor.

Emmanuel John
Oct 21, 2025 ⋅ 6 min read
Goodbye, useState? Smarter state modeling for modern React apps

Goodbye, useState? Smarter state modeling for modern React apps

Ever opened a React file and found a graveyard of useState hooks? The problem isn’t React; it’s how we model state. Here’s how to do it smarter.

Oscar Jite-Orimiono
Oct 21, 2025 ⋅ 9 min read

Why third-party integrations break in React 19 — And how to future-proof them

React 19 breaks old third-party integrations. Learn why concurrent rendering exposes brittle SDKs and how to rebuild them with resilient modern patterns.

Peter Aideloje
Oct 20, 2025 ⋅ 4 min read
React useEffectEvent: Goodbye to stale closure headaches

React useEffectEvent: Goodbye to stale closure headaches

Discover why the useEffectEvent Hook is important, how to use it effectively, and how it compares to useRef.

David Omotayo
Oct 17, 2025 ⋅ 5 min read
View all posts

3 Replies to "Why I (finally) switched to urql from Apollo Client"

  1. I’m not a author but I’ve used both Apollo and Relay, and I can defenitely say that Realy has worst development experience among graphQL client libraries. It’s concept of defining & generating artifacts require lots of workplace configuration and even after you deal with all of them, relay don’t provide that much of functions compared to others.

  2. This article inspired me to try urql, but urql inspired me to switch back to Apollo. Apollo was a huge pain to set up, but urql isn’t much better, and an issue with their reported types for cache variables (because, despite the claim that normalized caching “isn’t necessary”, list additions are necessary and optimistic updates are pretty close) meant I had to consider whether I was continuing to switch because of the sunk cost fallacy. Also, HOCs are a bit outmoded at this point, so I wouldn’t exactly consider their nextjs support all that wonderful, and when graphql-codegen gets thrown into the mix (necessary if you don’t want to write more boilerplate than code), Apollo’s mismanaged jumble of documentation due to old supported libraries and flawed initial practices seems preferable to me.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now