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:

Actix Web Adoption Guide: Overview, Examples, And Alternatives

Actix Web adoption guide: Overview, examples, and alternatives

Actix Web is definitely a compelling option to consider, whether you are starting a new project or considering a framework switch.

Eze Sunday
Mar 18, 2024 â‹… 8 min read
Getting Started With NativeWind: Tailwind For React Native

Getting started with NativeWind: Tailwind for React Native

Explore the integration of Tailwind CSS with React Native through NativeWind for responsive mobile design.

Chinwike Maduabuchi
Mar 15, 2024 â‹… 11 min read
Developing A Cross Platform Tv App With React Native

Developing a cross-platform TV app with React Native

The react-tv-space-navigation library offers a comprehensive solution for developing a cross-platform TV app with React Native.

Emmanuel Odioko
Mar 14, 2024 â‹… 10 min read
Essential Tools For Implementing React Panel Layouts

Essential tools for implementing React panel layouts

Explore some of the best tools in the React ecosystem for creating dynamic panel layouts, including react-resizable-layout and react-resizable-panels.

David Omotayo
Mar 13, 2024 â‹… 8 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