There are plenty of posts and articles about the differences between apollo to urql, but this is about the challenges specific to migrating from Apollo Client to urql.

At my workplace Mr Yum we recently made this migration on a large codebase with a mix of legacy and recently-written code. These are roughly ordered from most surprising and painful to the least noteworthy.

1. refetch (or reexecuteQuery in urql parlance) is not awaitable

We had a lot of code which refetched queries to refresh the data after calling mutations, because our graph does silly things like returning a boolean on update instead of the updated object itself. Mega painful stuff, which is still haunting us.

If this applies to you, just bite the bullet and update your mutations to return updated data (read more), it will speed up operations and allow you to leverage graphcache properly.

2. mutations don’t throw on errors

This was an expected change for us and intentional urql developer’s part but still led to a bunch of places where we “missed a spot”, and the code assumed that a mutation occurred successfully because code was still executing (since it did not throw).

From the urql docs:

“It’s worth noting that an error can coexist and be returned in a successful request alongside data. This is because in GraphQL a query can have partially failed but still contain some data.”

Just check const { error } = await updateThing() and take action depending on error accordingly.

3. graphcache is great

This isn’t a gripe, just a unexpected blessing. Where Apollo Client will explode if a query doesn’t or does have an id field when it shouldn’t or should, urql simply logs a warning to the console. It feels predictable, not fragile.