What made graphql-request better candidate to build base query function on than plain fetch?

[azangru]

Looking through the history of my repo, I see that I added a custom graphqlBaseQuery function, based on graphql-request, several months after you added rtk-query-graphql-request-base-query to the RTK monorepo. I am sure I wasn't even aware that rtk-query-graphql-request-base-query existed; I must have based mine on @phryneas's earlier example, which used graphql-request's request function, and looked nice and simple.

Years went by; graphql-request got updated to version 7, which I was unable to upgrade to for a long while because it was ESM-only, and I was running jest. Only recently, after finally migrating from jest to vitest, I updated all the dependencies that were previously blocked on jest, and realised that since version 7, graphql-request always requires that the url is absolute, where previously it was happy with relative urls. They are also deprecating the gql function, probably for a good reason. And although they still export the plain request function, they don't include it anywhere in their documentation.

All of this made me wonder — what is the benefit of using graphql-request in the context of RTK-Q? Why not build a graphql base query on top of plain fetch? What are the pitfalls I should be looking out for if I decide to migrate my graphqlBaseQuery function to plain fetch?

[phryneas]

what is the benefit of using graphql-request in the context of RTK-Q? Why not build a graphql base query on top of plain fetch?

Primarily: not one more thing that we need to maintain that already exists.
GraphQL in RTK Query is a very niche use case already, as in almost all but the most simple use cases you should probably prefer a GraphQL protocol aware cache (Apollo Client, uqrl, relay) over a generic per-request API cache (RTK Query, TanStack Query, swr). The format-aware caches can automatically cache and normalize your responses based on assumptions about the response format a GraphQL cache can make that a "generic" cache can't.

graphql-request is a well-maintained library and we don't need to reinvent the wheel.
If things there get too complicated with it (afaik that library is getting more complex recently), you can always roll your own base query.

There is nothing particularly complex around it, especially if you have full control over the server. If you were to write a fully generic solution, you'd have to be aware of specifics like that different HTTP codes are interpreted differenly in GraphQL over HTTP based on accept/content-type headers, but if you only talk with one server, you probably don't need to implement negotiation mechanisms for that.