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:

Vue.js logo over a dark, textured purple background. The article discusses using defineExpose and in Vue 3 to enhance component interaction and enable dynamic theming.

defineExpose and <style vars> in Vue 3 for component interaction and theming

Simplify component interaction and dynamic theming in Vue 3 with defineExpose and for better control and flexibility.

Clara Ekekenta
Nov 7, 2024 â‹… 8 min read
How to set up TypeScript with Node.js and Express

How to set up TypeScript with Node.js and Express

Explore how to integrate TypeScript into a Node.js and Express application, leveraging ts-node, nodemon, and TypeScript path aliases.

Aman Mittal
Nov 7, 2024 â‹… 10 min read
Cover image for es-toolkit, a Lodash alternative

es-toolkit, a Lodash alternative

es-toolkit is a lightweight, efficient JavaScript utility library, ideal as a modern Lodash alternative for smaller bundles.

Rishi Purwar
Nov 6, 2024 â‹… 5 min read
JS Logo Over Blue Background

The ResizeObserver API: A tutorial with examples

The use cases for the ResizeObserver API may not be immediately obvious, so let’s take a look at a few practical examples.

Kevin Drum
Nov 5, 2024 â‹… 9 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