Creating a GraphQL fetcher for nanoquery

[Contresito]

Hey, thanks for making this library! I've been using it for some time and it's a joy to use.

Right now I'm interested in using nanoquery to fetch from a GraphQL server, but I'm confused on how I would go about writing the fetcher function, and I couldn't find any examples about that on the docs.

I'm having trouble specifically with the fact that the fetcher can only take SomeKey values (so, strings, numbers or true).
Passing the query is easy enough, since it's just a string. But what about passing the variables object the body needs? Should I turn it into a string with JSON.stringify before passing it onto the fetcher, then do JSON.parse to it inside the fetcher to change it back into an object? That seems to work, but it looks like an ugly hack, so I must be missing something.

This is what I have right now:

import { nanoquery } from "@nanostores/query";

export const [createGQLFetcherStore, createGQLMutatorStore] = nanoquery({
  fetcher: (...[query, variables]) =>
    fetch(import.meta.env.PUBLIC_GQL_URL, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        query,
        variables: JSON.parse(variables as string),
      }),
    }).then((r) => r.json()),
});

So, how would it be done? :)

[ai]

The question for @dkzlv

[dkzlv]

Hey there, @Contresito!

It's generally up to you how you structure your fetcher functions. The way you did it works too, but I agree that looks a bit cumbersome, and may even have performance tax (more on that below).

Here's a demo of how I would approach that. The key takeaway is that I would not use the global fetcher function and instead define fetcher functions in every fetcher store individually. I would then define variables as keys, and just pass them into a generalized request function that fetches stuff from GQL endpoint. It's not too much of repetition, but it looks/behaves a bit better.

Feel free to ask more stuff. In general, if you have nanoquery-related questions, you should go to its repo. Over time we build up a database of popular questions, and responses may help other devs in future.

---

The reason why SomeKey is so strict is that this value gets serialized and stored for a very long time in cache. I'd say, comparing us to tanstack-query or swr, it's much easier for us to allow passing objects/arrays as keys, because we don't have to deal with render function, so we need to serialize those objects/arrays and run deep equality check only once per change, which is very good.

Nonetheless, we decide against that. Primary reason is that it would bloat cache/memory consumption too much.

Take my example above. It would be very tempting to put the whole query as key, right? But that would mean that this whole huge string will live in memory for every cache value! And if you decided to pass the whole response object from ExampleQuery instead of just the id, it would do too. After 50 runs you'd have 50 copies of objects and queries in memory, and GQL queries can be enormous, just like those entity objects.

So instead, we force you to use primitives—they are typically more space efficient. So, as you can see, I put query outside of keys and instead try to identify the fetcher store somehow (in this case it's list and byId, but feel free to be more descriptive). I think that's generally a much more sustainable approach.

[Contresito]

Thank you @dkzlv for the insightful response! Next time I'll ask on the proper repo :) I suppose creating an issue with the question label is fine?

Looks like I was limiting myself trying to mimic the REST example, I didn't think of defining the fetcher for every store, the way you did it is a much better approach!
I also appreciate the explanation on why you guys did nanoquery like this, thank you!

Just so I know I understand everything on your demo, the reason for giving a name (list and byId) on the keys is because the library needs you to pass something different as a key on every fetcher store so it can identify each one separately, is that true? But then wouldn't it be the same to just pass an empty array if you don't need any arguments for your fetcher, since arrays are all different from each other?

[dkzlv]

@Contresito We don't use dependency array as cache key, we always serialize them. Take this example:

const $id = atom(1);

const $postById = createFetcherStore([$id, 'some string', true]);

If we run this fetcher store, we'll get "1somestringtrue" as cache key. Literally, just cast to strings and join. Fetcher stores are basically an access point to cache, so if you were to create a fetcher store somewhere that would have the same key, it would have the same value!

const $forLulz = createFetcherStore('1somestringtrue'); // ← this will dedupe, use cached value, etc.
                                                        // but the fetcher function will probably break

That's the reason we need to uniquely identify the purpose of a fetcher store, because just passing id: number as key will match this fetcher store to other stores, and the whole thing will break.

In typical REST API usually path is sufficient. In GQL the query is what identifies a single fetcher store, but, as I said, it's so huge that I would avoid using it as is. But you definitely could if you think your cache won't grow too much. For example, if you have an app with short sessions and not something like Slack or Linear that sits in memory for days and weeks without reloads.

[Contresito]

I see, I understand now! Thank you for the explanation, hope you have a good rest of the day!