As the title says, we’re evaluating a new default GraphQL client, and we want to hear what you think about what we think.
Right now, Redwood uses Apollo Client. Apollo Client’s a complex tool, and on top of that, Apollo Client v3 just came out. It’s not a complete overhaul of v2 by any means, but some key things did change.
None of us are Apollo Client experts; if you are, we’d especially love to hear from you!
But even before that, many of us have had problems with Apollo Client. And it’s usually because of the cache. A fair share of the problems I’ve debugged on Discord have been about why some optimistic update didn’t work (or even how to do it in the first place), or why a Cell didn’t refresh.
We all know: caching is hard. No one’s saying it’s not. Updating a record with Apollo Client isn’t too bad, but creating and deleting one seems needlessly complex… Of course you always hope that it’s not needlessly complex for no reason. And there are a whole bunch of reasons for it to be the way it is (TL;DR normalization). But then it makes you wonder: do we really need normalization in the first place? Sure, we might want it at some point, but out of the gate? It just doesn’t seem to be what most users are worried about.
In some sense, which GraphQL client Redwood uses should be an implementation detail. But in some places, like Scaffolds, it surfaces. Since scaffolds are in many ways, the way that people learn Redwood, we have to be a little more careful.
In considering all this, we always have to remember Redwood’s goals: what does Redwood want to be, do, offer?
The mantra that probably comes to all of our minds: convention over configuration. Another is “make easy things easy and hard things possible”. Redwood should be, by default, providing what you probably want, but also let you change it.
So is Apollo Client what you probably want? And if it’s not, are we letting you change it? Both of these questions are the premise for our evaluation and this post.
We’re thinking about making urql Redwood’s default GraphQL client.
Why urql? We’re still doing our research, but here’s one aspect we know we like right off the bat: it’s more layered. Not everyone needs a complex cache (or even a cache at all), and especially not right out of the box. urql’s more basic document caching, with its aggressive invalidation, is, in the beginning, probably more than enough. And if you want normalization, you can add it with Graphcache.
It really does depend on your app, but Redwood’s still really early, so we’re going to optimistically say: not much! At least not much more than the switch from Apollo Client v2 to v3 anyway .
The only thing that we can say for sure is that you’d have to provide a useQuery hook to Cells so that we can make Cells work with whatever GraphQL client you choose to use.
Yes! This change would make it possible to configure a GraphQL client of your choice, while still providing a sane default (right now, the candidate for that is urql) if you choose not to.
We’re still early in the process, but we want to know what you think now before we get too into the weeds. Thanks for reading and please let us know!