1661
⋅ 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:

8 Tips To Reduce Unused Javascript

8 tips to reduce unused JavaScript

Knowing how to reduce unused JavaScript can help you save time, optimize performance, and improve efficiency.

Abhinav Anshul
Nov 27, 2023 ⋅ 5 min read
Guide to mobile emulator testing with MiniSim

Guide to mobile emulator testing with MiniSim

MiniSim makes virtual emulator testing easy — learn how to use it to test both Android and iOS apps on macOS in this detailed post.

Emmanuel John
Nov 22, 2023 ⋅ 5 min read
Implementing safe, dynamic localization in TypeScript apps

Implementing safe, dynamic localization in TypeScript apps

After internationalization, you can further localize your apps to make user experiences more friendly. Learn how to do this in TypeScript.

Yan Sun
Nov 21, 2023 ⋅ 6 min read
Using Dev Containers In Vs Code For An Easier Dev Setup Process

Using dev containers with VS Code for an easier dev setup

You can leverage containers to streamline the process of setting up a dev environment. Let’s see how using VS Code and Docker.

Yashodhan Joshi
Nov 21, 2023 ⋅ 11 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