multiple clients

[Manubi]

Hi,

I need to query two different graphql servers. One is www.example.com/api/graphql/ the other one is www.example.com/internal/api/graphql. I know it's not the common way of doing things, but I need to implement it... And as I wanted to try urql I was wondering how I can do it.

I know it's possible with apollo to add a second client. Something like ApolloClients { default: publicClient, private: privateClient}

Is there an easy version for urql as well?

Thanks a lot!

[JoviDeCroock]

I'd suggest creating an abstraction over the hooks honestly, where you use the context argument to our hooks to supply a different url. For insance:

const useMyCustomQuery = ({ internal, ...args }) => useQuery(...args, context: useMemo(() => ({ url: internal ? 'x' : 'y' }), [])

[Manubi]

Thanks for the quick reply. I am unfortunately using vue3.

So far I have this.

    const result = useCustomQuery({
      internal: true,
      query: NEWS_ARTICLES_QUERY
    });

export default function useCustomQuery({ internal, ...args }: any) {
  const context = { url: internal ? "/internal/api/graphql" : "/api/graphql" };
  return useQuery({ ...args, context });
}

Can you help me with the typings? Thanks!

[JoviDeCroock]

Something like:

import { useQuery, UseQueryArgs } from '@urql/vue';

export default function useCustomQuery<Data, Variables>(
  { internal, ...args }: UseQueryArgs<Data = any, Variables = object>
): UseQueryResponse<Data, Variables> {
  const context = { url: internal ? "/internal/api/graphql" : "/api/graphql" };
  return useQuery({ ...args, context });
}

[nandorojo]

@JoviDeCroock I notice you didn't memoize the context here. I assume this is just pseudocode for the types, but to clarify, will requests refetch when the context reference changes? (I would like them to, but just checking.)

[JoviDeCroock]

You are right to point this out, you should memoize it, then when url changes it will refetch yes. In your case:

const context = useMemo(() => ({ url: internal ? "/internal/api/graphql" : "/api/graphql" }), [internal]);

[ceefour]

Was discussed before in issue #429

[vilchesalves]

Hey urlq people. :)

I'd like to +1 this, with my quite extreme use case: we have multiple microservices served in AWS AppSync endpoints, and for top down architectural decisions we currently have 5 different graphql endpoints for the frontend to handle.

With Apollo we were initially importing and using clients locally, but recently we managed to split the link dynamically.

Is the approach here to just overwrite the top client url with a local url in the context of the useQuery?
Is it worth it to have the approach added to the documentation?

Cheers!

[ceefour]

@Manubi This is interesting. Can you share your experience why you moved away from Hasura, and approaching multiple GraphQL clients instead?

[JoviDeCroock]

@Manubi writing an exchange won't have you touching the custom-hooks.

Also hooks look like this:

export function useFindUserQuery(options: Omit<Urql.UseQueryArgs<FindUserQueryVariables>, 'query'> = {}) {
  return Urql.useQuery<FindUserQuery>({ query: FindUserDocument, ...options });
};

Those options permit you to pass in the aforementioned context.

[Manubi]

@Manubi This is interesting. Can you share your experience why you moved away from Hasura, and approaching multiple GraphQL clients instead?

I just moved away from Hasura because the bigger the projects gets the more cumbersome development with hasura gets. Also the onboarding of new devs just takes too long. Because everyone is afraid of touching something because nobody knows what's going on.

[Manubi]

Hey again,

I am looking into the exchange stuff which you can find here. I wanted to pass a new context property with the client in order to read it in the exchange from the client and then change the URL if needed. But somehow I get an error when fetching the articles.

I want to read it from the client in the exchange:

export default function noopExchange({ client, forward }: any) {
  console.log("client", client.context.newUrl);
  console.log("forward", forward);
  return (operations$: any) => {
    // <-- The ExchangeIO function
    const operationResult$ = forward(operations$);
    return operationResult$;
  };
}

Anyone? thanks

[kitten]

@Manubi The client doesn't carry the context as it's more like an event hub or manager of operations. It only carries options with it. The input from your bindings (or calls to the Client) and the Client's base options combine into forming operations.

So when you're writing an exchange you're dealing with a stream of operations coming from the client or the last exchange in the chain, which you can then transform and forward. This stream then goes on since forward refers to the next exchange in your pipeline.

Each exchange then returns a stream of results, so that's what forward returns. In other words, we're piping a stream in and composing a stream back with results too. https://formidable.com/open-source/urql/docs/architecture/

Each Operation is unique and carries its own instance of a context on it, the kind of operation, a key, and the original query and variables https://formidable.com/open-source/urql/docs/api/core/#operation

If you're modifying the context in a binding it's hence different from operation to operation. This is important so that each operation can actually have separate parameters.

You can actually see a simple example here: https://formidable.com/open-source/urql/docs/common-questions/#how-do-we-achieve-asynchronous-fetchoptions
But in practice, all you'll need is to map the incoming operations to change the context.

I'd still recommend you however to consider a directive on the query, e.g. @api(url: "..."), since this will not only ensure that your query's key will change, but since it'll also potentially allow you to integrate code/type generator tools more easily in the future with some custom plugins.

[Mookiies]

If using React a way to workaround the single client limit is by nesting another Provider with a different client. This works because Providers can be nested to override values deeper within the tree.

This can work well without getting complicated so long as the nested parts of the tree only need to use one client.

[remon-nashid]

@Mookiies good idea! I wonder, how do you get to specify the client needed when calling useQuery?

[remon-nashid]

Gotcha! So a Provider is specific to a tree of components, as you suggested.

[Mookiies]

useQuery uses the client that it gets from the provider, which is determined by the closest Provider in the tree. So your usage of useQuery wouldn't specify anything, the client is determined by the react tree.

For example here Component1 and Component2 will use client1. However Component3 will use client2 because of the nested provider.

Index:

  <Provider value={client1}>
    <YourRoutes />
  </Provider>

YourRoutes

const client2 = createClient({});
...
<>
   <Component1 />
   <Component2 />
   <Provider value={client2}>
      <Component3 />
   </Provider>
</>

[Manubi]

Works like a charm! thanks :D

[tomduncalf]

The way I've solved this was inspired by what kitten wrote in #1523 (reply in thread).

My use case is I am using a hosted CMS (DatoCMS) which has a GraphQL API, and also have a local API for e-commerce cart operations. I could proxy the CMS API through my local API, but that makes no sense as it massively increases the amount of traffic the local API has to handle.

I am using graphql-codegen to generate my hooks, so didn't want to have to manually mess with the hooks. Instead, I created an exchange which modifies the operation's URL and headers (as each API has a different authentication mechanism) based on the name of the selection set – i.e. the "thing" you are querying (lol – I'm new to GraphQL so not sure if there's a better term) – e.g. in this case, it would be cart:

query GetCart {
  cart {
    id
    items {
      product {
        name
      }
    }
  }
}

I have an array of selection set names which should be sent to my local API, and the rest get sent to the CMS. This probably wouldn't work for more complex queries, but it works for my use case and could be expanded to use whatever details of op you care about, just log it out and see what is in there.

const API_QUERY_SELECTION_SETS = ["cart", "clearCart"];

const urlSplitterExchange = ({ forward }) => {
  return (ops$) => {
    const shared = pipe(ops$, share);

    // Split out queries/mutations, which we want to handle...
    const queries = pipe(
      shared,
      filter((op) => op.kind === "query" || op.kind === "mutation"),
      onPush((op) => {
        // Get each operations first selection set and check if it's in API_QUERY_SELECTION_SETS
        // and set the URL and headers accordingly
        const selectionSet = op.query.definitions[0].selectionSet.selections[0].name.value;
        if (API_QUERY_SELECTION_SETS.includes(selectionSet)) {
          op.context.url = API_URL;
          op.context.fetchOptions.headers = API_HEADERS;
        } else {
          op.context.url = DATO_URL;
          op.context.fetchOptions.headers = DATO_HEADERS;
        }
      })
    );

    // ...and other messages, which we just forward
    const others = pipe(
      shared,
      filter((op) => !(op.kind === "query" || op.kind === "mutation"))
    );

    return forward(merge([queries, others]));
  };
};

Then add this exchange before the fetchExchange.

So with the above example, queries or mutations named cart or clearCart go to the local API, everything else goes to the CMS. Hope this helps someone!

Cheers,
Tom

[remon-nashid]

The problem with changing client's URL on the fly, is that cache is unintentionally shared. If you send a query to Url1, then for whatever reason, send the same query to Url2, you'll hit the cached response of Url1.

[tomduncalf]

True, it would be nice if there were a better way to work around this

[agcty]

I'm using urql to fetch some data from the graph (graphql for ethereum basically). I have a similar issue with using different URLs, I need to fetch a lot of different data from different graph endpoints and desperately need a nice way of using different urls.

[JoviDeCroock]

Hey, you can leverage your own exchange for this

import { dedupExchange, cacheExchange, fetchExchange, createClient } from 'urql';
import {
  makeOperation,
  Operation,
  OperationResult,
  Exchange,
} from '@urql/core';
import { pipe, tap, map } from 'wonka';

// You can use options for inputs if you want to make this reusable for  the community
export const requestPolicyExchange = (options): Exchange => ({
  forward,
}) => {
  const processIncomingOperation = (operation: Operation): Operation => {
    if (operation) {
      // your own condition
      return makeOperation(operation.kind, operation, {
        ...operation.context,
        url: 'some-url',
      });
    }
    
    return operation
  };

  return ops$ => {
    return pipe(
      map(processOperation),
      forward(ops$),
    );
  };
};

const client = createClient({
  url: 'some-url',
  exchanges: [dedupExchange, cacheExchange, myExchange(), fetchExchange]
})

[agcty]

With this code, do I still need different providers for caching? 🤔

[JoviDeCroock]

This uses 1 cache for all data, from my knowledge of the graph that shouldn't be an issue 😅 but my knowledge is quite limited in all honesty. We currently don't have a url-segmented cache but in essence it should be possible to implement

[mwilc0x]

Thank you for this helpful example!

I had to make a small change to get this working in my code, from the docs. In case anyone new sees this!

return ops$ => {
  return pipe(
    ops$,
    map(processIncomingOperation),
    forward,
  );
};

[AjayiMike]

Unfortunatelly, this approach doesn't work for me.

seems like requestPolicyExchange held on to the first context. it doen't update to change the endpoint in subsequent calls.

This is my code.

import { ReactNode } from 'react';
import {
    cacheExchange,
    Client,
    Exchange,
    fetchExchange,
    makeOperation,
    Operation,
    Provider as UrqlProvider,
} from 'urql';
import { authExchange, AuthConfig } from '@urql/exchange-auth';
import { SUBGRAPH_ENDPOINTS } from '@/constants/urls';
import { DEFAULT_CHAIN_ID } from '@/constants/chains';
import { map, pipe } from 'wonka';

interface IAppUrqlProvider {
    children: ReactNode;
}

export interface Options {
    endpoints: {
        [chainId: string]: string;
    };
}

const options: Options = {
    endpoints: SUBGRAPH_ENDPOINTS,
};

const AppUrqlProvider: React.FC<IAppUrqlProvider> = ({ children }) => {
    const client = new Client({
        url: SUBGRAPH_ENDPOINTS[DEFAULT_CHAIN_ID],
        exchanges: [
            cacheExchange,
            authExchange(
                async (utils) =>
                    ({
                        addAuthToOperation: (operation) =>
                            utils.appendHeaders(operation, {
                                Authorization: `Basic ${btoa(
                                    `${process.env.NEXT_PUBLIC_SUBGRAPH_USERNAME}:${process.env.NEXT_PUBLIC_SUBGRAPH_PASSWORD}`
                                )}`,
                            }),
                    }) as AuthConfig
            ),
            requestPolicyExchange(options),
            fetchExchange,
        ],
    });
    return <UrqlProvider value={client}>{children}</UrqlProvider>;
};

export default AppUrqlProvider;

export const requestPolicyExchange =
    (options: Options): Exchange =>
    ({ forward }) => {
        const processIncomingOperation = (operation: Operation): Operation => {
            if (operation) {
                const endpoint =
                    options.endpoints[operation.context.clientNetworkId] ?? options.endpoints[DEFAULT_CHAIN_ID];

                return makeOperation(operation.kind, operation, {
                    ...operation.context,
                    url: endpoint,
                });
            }

            return operation;
        };

        return (ops$) => {
            return pipe(ops$, map(processIncomingOperation), forward);
        };
    };

How do I know?

the result.operation.context.networkClientId is not the same with networkClientId passed in the context when logged

The hook

const useSubgraphQuery = (
        query: any,
        context: { [key: string]: any },
        variables: { [key: string]: any },
        requestPolicy = 'network-only' as RequestPolicy
    ) => {
        const [result] = useQuery({
            query,
            variables,
            context,
            requestPolicy,
        });

        console.log({ result, context });

        return result;
    };