Offline subscriptions and mutations

[qpre]

Hi !

I'm currently experiencing with urql for an app that uses Hasura for the graphql backend.

In my app there is a webchat that relies on a subscription to get the messages and a mutation to insert them.

using the offlineExchange and an optimistic answer I'm able to store a message that is sent while offline and then have it sent when the connexion comes back.

Although, when offline I thought that using a writeFragment would be enough to "send" the temporary message to the subscriptions on messages but it does not seem to happen.

Here's how I'm handling the provider:

const GraphQLProvider = ({ children }) => {
  const { auth, signed_in } = useAuth();
  const token = useMemo(() => auth?.getJWTToken(), [auth, signed_in]);

  const { client, subscriptionClient } = useMemo(() => {
    const subscriptionClient = new SubscriptionClient(WS_ENDPOINT, {
      reconnect: true,
      connectionParams: () => ({
        headers: get_headers(auth),
      }),
    });

    const client = new Client({
      url: HTTP_ENDPOINT,
      requestPolicy: 'cache-and-network',
      fetchOptions: () => {
        return {
          headers: get_headers(auth),
        };
      },

      exchanges: [
        devtoolsExchange,
        dedupExchange,
        offlineExchange({
          schema,
          storage,
          updates: {},
          optimistic: {
            // The name of the field
            insert_messages_one: (variables, cache, info) => {
              const fragment = gql`
                fragment _ on messages {
                  id
                  sender_id
                  manager_id
                  volunteer_id
                  trial_id
                  created_at
                  content
                }
              `;

              const temp_message = {
                __typename: 'messages',
                id: new Date().getTime(),
                created_at: new Date().getTime(),
                ...variables.object,
              };

              cache.writeFragment(fragment, temp_message);

              return temp_message;
            },
          },
        }),
        fetchExchange,
        subscriptionExchange({
          forwardSubscription: (operation) =>
            subscriptionClient.request(operation),
        }),
      ],
    });

    return { client, subscriptionClient };
  }, [auth, token, schema]);

  return <Provider value={client}>{children}</Provider>;
};

Any idea of what I might have done or understood wrong ?

[kitten]

It looks like that write is redundant and in the wrong place? The write isn't needed if you emulate your mutation but you do need to have the message added to a list for it to show up probably https://formidable.com/open-source/urql/docs/graphcache/cache-updates/

[qpre]

Thanks for your answer !

It did indeed feel extraneous ˆˆ.

I'm feeling a bit lost when I read the documentation as I do not understand the relation between createTodo updateTodoDate in :

mutation NewTodo($text: String!) {
  createTodo(id: $todoId, text: $text) {
    id
    text
  }
}

and

cacheExchange({
  updates: {
    Mutation: {
      updateTodoDate(result, _args, cache, _info) {
        const TodoList = gql`
          {
            todos {
              id
            }
          }
        `;

        cache.updateQuery({ query: TodoList }, data => {
          data.todos.push(result.createTodo);
          return data;
        });
      },
    },
  },
});

For my case, I tried writing it this way:

const GraphQLProvider = ({ children }) => {
  const { auth, signed_in } = useAuth();
  const token = useMemo(() => auth?.getJWTToken(), [auth, signed_in]);

  const { client, subscriptionClient } = useMemo(() => {
    const subscriptionClient = new SubscriptionClient(WS_ENDPOINT, {
      reconnect: true,
      connectionParams: () => ({
        headers: get_headers(auth),
      }),
    });

    const client = new Client({
      url: HTTP_ENDPOINT,
      requestPolicy: 'cache-and-network',
      fetchOptions: () => {
        return {
          headers: get_headers(auth),
        };
      },

      exchanges: [
        devtoolsExchange,
        dedupExchange,
        offlineExchange({
          schema,
          storage,
          updates: {
            Mutation: {
                insert_messages_one(result, _args, cache, _info) {
                    const MessagesList = gql`
                      {
                        messages {
                          id
                          sender_id
                          content
                          created_at
                        }
                      }
                    `;
            
                    cache.updateQuery({ query: MessagesList }, data => {
                      data.messages.push(result.insert_messages_one);
                      return data;
                    });
                  },
            }
          },
          optimistic: {
            // The name of the field
            insert_messages_one: (variables, cache, info) => ({
                __typename: 'messages',
                id: new Date().getTime(),
                created_at: new Date().getTime(),
                ...variables.object,
              }),
          },
        }),
        fetchExchange,
        subscriptionExchange({
          forwardSubscription: (operation) =>
            subscriptionClient.request(operation),
        }),
      ],
    });

    return { client, subscriptionClient };
  }, [auth, token, schema]);

  return <Provider value={client}>{children}</Provider>;
};

But data in the update handler is always null.
After reading the docs and issues I'm pretty sure I'm missing something basic but still can't get my head around it.

[kitten]

Yep, that looks about right. But you do have to make sure that the query data you're updating actually exists in the cache

[qpre]

so if I have a view with a subscription that says:

const SUB_TO_MESSAGES_FOR_USER = gql`
subscription ($user_id: uuid!) {
    messages(
      where: {sender_id: { _eq: $user_id } } }
      order_by: { created_at: desc }
    ) {
      id
      sender {
        id 
        name
      }
      created_at
      content
    }
  }
  `;

this should work, shouldn't it ?

const GraphQLProvider = ({ children }) => {
  const { auth, signed_in } = useAuth();
  const token = useMemo(() => auth?.getJWTToken(), [auth, signed_in]);

  const { client, subscriptionClient } = useMemo(() => {
    const subscriptionClient = new SubscriptionClient(WS_ENDPOINT, {
      reconnect: true,
      connectionParams: () => ({
        headers: get_headers(auth),
      }),
    });

    const client = new Client({
      url: HTTP_ENDPOINT,
      requestPolicy: 'cache-and-network',
      fetchOptions: () => {
        return {
          headers: get_headers(auth),
        };
      },

      exchanges: [
        devtoolsExchange,
        dedupExchange,
        offlineExchange({
          schema,
          storage,
          updates: {
            Mutation: {
               insert_messages_one(result, _args, cache, _info) {
                  cache.updateQuery(
                    {
                      query: SUB_TO_MESSAGES,
                      variables: { user_id: auth.getClaim('x-hasura-user-id') },
                    },
                    (data) => {
                      debugger;
                      data?.messages?.push(result.insert_messages_one);
                      return data;
                    }
                  );
                },
              },
            }
          },
          optimistic: {
            // The name of the field
            insert_messages_one: (variables, cache, info) => ({
                __typename: 'messages',
                id: new Date().getTime(),
                created_at: new Date().getTime(),
                ...variables.object,
              }),
          },
        }),
        fetchExchange,
        subscriptionExchange({
          forwardSubscription: (operation) =>
            subscriptionClient.request(operation),
        }),
      ],
    });

    return { client, subscriptionClient };
  }, [auth, token, schema]);

  return <Provider value={client}>{children}</Provider>;
};

alas, be it with or without the variables field data remains {messages: null, __typename: "subscription_root"}.

It does work if I use a query instead of a subscription though !
But in case of a "live" chat it seems counter-intuitive to poll a query when we have subscriptions in our toolbelt.

[kitten]

Ah, I see what you mean. Subscriptions and mutations are a little special in that they're ephemeral side effects. In other words, you'd expect to get a different message every time you have a subscription result. This has an effect on how normalised caches treat them and it's described in our introduction page to normalised caching: https://formidable.com/open-source/urql/docs/graphcache/normalized-caching/

a GraphQL schema creates a tree of types where our application's data always starts from the Query root type and is modified by other data that's incoming from either a selection on Mutation or Subscription. All data that we query from the Query type will contain relations between "entities", JSON objects that are hierarchical.

This means that all data in your application is described by queries. Each piece of data is described by paths from your query root type.

Imagine you had only a subscription, what would your method be to retrieve past messages? A subscription would typically be used to notify you of incoming messages but not of any past ones.

Hence you'd typically also have a query to retrieve all messages (paginated or not doesn't matter here). So, queries describe the "ground truth" of your data and mutations and subscriptions describe modifications of your data. The normalised caches tires everything with the assumption that queries describe your state and mutations and subscriptions describe updates.

This is why when you write manual updates for the normalised cache data, it's required to modify data as it's known from queries.

[qpre]

I see !

Hasura uses a different paradigm for subscriptions where they are more like « live queries » : they do not give you incremental updates but full results for the subscription so you can use them as you would queries and the returned data is always the latest revision from the server.

I understand how graphcache has to be the most versatile for all graphql users. It feels like there would be room for an opiniated cache for Hasura’s and their normalized schema.

Thanks a lot for your answers, I think this closes the topic for me !