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:

i tried kiro and here is what i learned

I tried out Kiro: Here’s what I learned

Check out Kiro, AWS’s AI-powered IDE, see what makes it different from other AI coding tools, and explore whether it lives up to the hype.

Elijah Asaolu
Aug 28, 2025 â‹… 5 min read
Go Design Pattern Article Image With Logo

Why Go design patterns still matter

Here’s how three design patterns solved our Go microservices scaling problems without sacrificing simplicity.

Peter Aideloje
Aug 28, 2025 â‹… 2 min read
how to protect your ai agent from prompt injection attacks

How to protect your AI agent from prompt injection attacks

Explore six principled design patterns (with real-world examples) to help you protect your LLM agents from prompt injection attacks.

Rosario De Chiara
Aug 27, 2025 â‹… 5 min read
Don’t Let AI Erase The Next Generation Of Dev Leaders

Don’t let AI erase the next generation of dev leaders

As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.

Jack Herrington
Aug 26, 2025 â‹… 6 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