Can SWR totally replace react-apollo?

[mdegrees]

I'm maintaining a Next js application that relies on Apollo to fetch data, infinite scroll and do updates in realtime (chat like updates). SWR seems to work better with Next js with no boilerplate code. I'm considering migrating to SWR but have no idea how to replicate some react-apollo features like components subscribing to updates via Graphql. Are there any examples of SWR working with graphql Subscriptions as in react-apollo https://www.apollographql.com/docs/react/data/subscriptions/?

[mdegrees]

Although I generally understand this example: #41 (comment), I have no idea how on a socket event, a newComment for e.g, we do update the data from api/allComments.

Can you please provide a full cycle example? something like fetching api/allComments > emitting a new comment > reacting to the new comment by appending it to api/allComments data.

With react apollo, it's something like:

const GET_COMMENTS_QUERY = gql`
  query GetComments() {
      comments {
        id
        content
      }
  }
`;

const COMMENTS_SUBSCRIPTION = gql`
  subscription onCommentAdded() {
    commentAdded() {
      id
      content
    }
  }
`;

function CommentsPage({ params }) {
  const { subscribeToMore, ...result } = useQuery(GET_COMMENTS_QUERY);

  return (
    <CommentsPage
      {...result}
      subscribeToNewComments={() =>
        subscribeToMore({
          document: COMMENTS_SUBSCRIPTION,
          variables: { repoName: params.repoName },
          updateQuery: (prev, { subscriptionData }) => {
            if (!subscriptionData.data) return prev;
            const newFeedItem = subscriptionData.data.commentAdded;

            return Object.assign({}, prev, {
              entry: {
                comments: [newFeedItem, ...prev.entry.comments]
              }
            });
          }
        })
      }
    />
  );
}```

Thank you!
 

[vasco3]

can the swr mutation run a refetchQueries like apolo useMutation does?

[sergiodxa]

@vasco3 if you have the query you used to get the data in useSWR you could run mutate(GET_COMMENTS_QUERY) and SWR will revalidate that query which means it will run it again, but you need to know the exact queries you want to run, to be more correct you need to know the keys useSWR received so that could be the query + variables in some cases.

[vasco3]

@sergiodxa that would work. Thanks

[HofmannZ]

Intresting! Going to play with this!

[vasco3]

Now that I'm implementing, I realize that mutate only mutates locally but doesn't replaces useMutation.. am I correct? In case of using Swr SWRConfig I need to pass the fetcher through React Context to the component where I want to replace useMutation. Am I correct?
Would be convenient that the fetcher would be available as an output from useSWR(). That way i wouldn't need to import an additional context to reuse the global fetcher.

[sergiodxa]

You don’t need fetcher to call mutate, if you only pass the cache key that will make the useSWR calls revalidate the data

[vasco3]

I know, but I need to also mutate the database. According to the docs

mutate: function to mutate the cached data

I'm using the fetcher to post the mutation to the serverside. Or which would be the ideal case?

For example: I'm fetching a list of users (id and user name). Then I edit a user name. I use mutate to update locally and useSWR([updateUser, newUserName], fetcher) to update de database.

[sergiodxa]

This is what I usually do (simplified):

function UserList() {
  const { data } = useSWR("/api/users", fetcher, { suspense: true });
  
  return data.map(user => <User key={user.id} {...user} />)
}

Then, somewhere else, when I need to update a single user, let's say inside the User component, I have a function like this:

async function updateUser(id, fields) {
  const res = await fetch(`/api/users/${id}`, { method: "PATCH", body: JSON.stringify(fields) });
  mutate("/api/users");
}

And now my list of users will revalidate itself and get the updated user, so I first mutate the DB (PATCH to the API) and then trigger a revalidate to GET the updated list, most of the time the GET is fast enough to don't feel a difference, if I needed and Optimistic UI update I would do something like:

async function updateUser(id, fields) {
  // this does the optimistic UI to the list
  mutate("/api/users", users => { /* find and update user here */ }, false);
  // here we mutate the DB
  const res = await fetch(`/api/users/${id}`, { method: "PATCH", body: JSON.stringify(fields) });
  // here we revalidate the list to ensure we are always up-to-date with the DB
  mutate("/api/users");
}

[vasco3]

Ok I see. In my case I'm using import { GraphQLClient } from 'graphql-request'; and I need to add an authorization header since I'm using FaunaDB's graphql (I also use Monday.com's graphql API).

So my fetcher is passed in nextjs _app.js

<SWRConfig value={{ fetcher }}>
    <Component {...pageProps} />)}
</SWRConfig>

and my fetcher looks like this

   const fetcher = (query, source = 'FAUNA', ...args) => {
      const graphQLClient = (src => {
        switch (src) {
          case 'MONDAY':
            return new GraphQLClient('https://api.monday.com/v2', {
              headers: { authorization: org?.settings?.mondayApiKey?.config },
            });

          case 'FAUNA':
          default:
            return new GraphQLClient('https://graphql.fauna.com/graphql', {
              headers: {
                authorization: `Bearer ${org?.serverSecret}`,
                'X-Schema-Preview': 'partial-update-mutation',
              },
            });
        }
      })(source);

      // Creates an object. Odd indexes are keys and even indexes are values.
      // Needs to be flat to avoid unnecessary rerendering since swr does shallow comparison.
      const variables = [...(args || [])].reduce((acc, arg, index, arr) => {
        if (index % 2 === 0) acc[arg] = arr[index + 1];
        return acc;
      }, {});

      return graphQLClient.request(print(query), variables);
    };

That's why I would like to reuse the fetcher to call my external mutation calls.

I'm not happy about having the auth token on runtime JS. I would rather have it on an http-only cookie, but I see no other way to make it work with Fauna's graphql (I think they are working on this case).

It helps to see your approach, thanks

[HofmannZ]

@vasco3 we use a service worker to inject auth headers into specific requests. You could try use that here?

[vasco3]

@HofmannZ what is the advantage of using a service worker for this? I'll take a look

[ivan-kleshnin]

Proponents of GraphQL + SWR combination 🙏

How do you approach query revalidation with the way it's shown in docs?

  useSWR(
    `{
      Movie(title: "Inception") {
        releaseDate
        actors {
          name
        }
      }
    }`,
    fetcher
  )

The best thing I can imagine is to export all queries and revalidate them by names:

 useSWR(
  MOVIES_QUERY,
  fetcher
)

Apollo-Client (being as hard to use as it is) has at least some rudimental convienience.
For example, cache updates for UPDATE queries are resolved automatically.
Also, cached models can be updated directly (query caches reference model caches).

I don't see any benefit of SWR over Apollo-Client, except for the lower entry barrier for the simplest of cases.
The complex ones will be much harder and you'll reimplement Apollo cache mechanics in the best scenario.
I wish to be proven wrong because I don't really like Apollo-Client 😉

---

Update: URQL a better choice than Apollo-Client for 2021 i.m.o. Apollo-Client development is stagnating while URQL has made a great progres in terms of docs and stability. I'ved used both document-based and graph-based caches successfully.
There's no need to write manual cache updates in URQL – just define dependent types. The worst feature of Apollo is not present in URQL.

TLDR: choose SWR for REST APIs and Urql for GraphQL APIs – you won't regret.

[redbar0n]

@ivan-kleshnin Writing manual cache updates can be avoided in Apollo Client too, it seems:

“Instead of updating Apollo Client’s cached queries manually, using its refetchQueries prop provides a shortcut for updating your User Interface after a mutatuion.”

https://medium.com/@timothyde/escaping-cache-update-hell-in-apollo-client-c09d3a4c9a5e

[ivan-kleshnin]

@redbar0n it's very different. In Apollo's refetchQuery you has to couple queries with other queries. In Urql you just list types. In practice, the list of related types tends to be much shorter and predictable than the list of related queries. Also refetchQuery sometimes requires you to pass variables, not just a query string. Which you typically don't know and so you cannot update the cache in this manner. The best way to escape cache update hell in Apollo is to ditch the library itself.

[redbar0n]

@ivan-kleshnin That's a great explanation, thanks for clarifying. <3

Since you seem to know both Apollo Client and URQL in depth, would you mind adding a column for URQL to this community-edited comparison page?
It would really help out newcomers trying to evaluate the right tool for their job. React Query looks like a decent and up and coming alternative to either SWR or URQL, and I'm a bit baffled... (React Query's comparison page has SWR and is more detailed and than URQLs own comparison page, but the latter page could be used as a starting point).

[redbar0n]

It does not seem like SWR supports subscriptions: Comparison of React Query, SWR, Apollo Client, Relay

Subscriptions seem like an edge use case, according to Apollo's subscriptions doc: "In the majority of cases, your client should not use subscriptions to stay up to date with your backend. Instead, you should poll intermittently with queries, or re-execute queries on demand when a user performs a relevant action."

You can apparently use the apollographql/graphql-subscriptions small npm module with any GraphQL client and server (not only Apollo).

Hope this helps someone.