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;
    };

[NotFounds]

Hello! Thank you for the awesome library.

Could you please reconsider #446.
We are using our own service's GraphQL API and a third-party provided GraphQL API on a single page. There are plenty of cases where a SaaS public API is exposed as a GraphQL API, so we believe that "GraphQL usually ties multiple APIs together and hence this doesn't really come up as we've seen." does not apply. (Examples of SaaS exposing GraphQL APIs: GitHub, Shopify, Stripe)

If using multiple SaaS APIs in a client is not recommended, what would be the best approach?

[kitten]

There are plenty of cases where a SaaS public API is exposed as a GraphQL API

There are plenty of cases, yes, but all of the examples you've given just to make this clear, are APIs that you have to authenticate with.
Just to illustrate this, you wouldn't want your Stripe API tokens to be public and shared in a web application, right?

To take a step back, with GraphQL, at the end of the day we "just" build APIs. And there's nothing stopping us from accessing any API from our web app, and there's nothing even stopping you from adding multiple sub-sections to your app, or multiple urql clients, with some limitations.

However, when we speak about third-party APIs in your UI, we're speaking about losing basically all the benefits of GraphQL. Just because you're interacting with a GraphQL API, that doesn't mean it's your GraphQL API, and you basically are losing benefits of schema design.

So, not to be rude, but it is a bit tongue in cheek 😅❤️, your example actually perfectly demonstrates why we don't even support this

[NotFounds]

Thank you for the quick reply.
You are right, the examples of GitHub and Stripe were not appropriate. My bad.

you basically are losing benefits of schema design.

I understand.

However, Shopify seems to only provide a GraphQL API for the frontend. And, it appears that this API does not require authentication. If my understanding is correct, to use Shopify in a headless manner and build a UI, one must use the GraphQL API. By the way, there is a public token for API calls, so it seems there is no problem calling it from the browser.
https://shopify.dev/docs/api/storefront#authentication

Sorry for bringing up specific product examples. Should we integrate multiple APIs even in such cases?

[kitten]

one must use the GraphQL API

Yes, but this is a service API. For example, say you're using an API with public resources. Even though you could access its data from the front-end that doesn't mean that that's a good idea.

Say you've got a CMS, a shop API, and a payments API. For the sake of the argument, let's say they all have public APIs that could be accessed from the front-end directly (i.e. CMS has a public GraphQL API for content, the shop has a public, unauthenticatd API for products, and the payment API has replicated products for the shop and payments can be initiated publicly by creating a cart via GraphQL).

Just because all three APIs could be accessed from the frontend that doesn't mean it makes much sense in the context of urql and a GraphQL client. You'd be stuck having to stitch data to different data sources on the front-end, e.g. CMS says "list product A" then you look up the shop API for cart details "get product A by external ID", and then you create a cart entry via the payment API "for product A with external ID add it to cart". You basically end up doing something on the front-end that negates all strengths of GraphQL. At this point and with this usage, it basically doesn't matter that you're using GraphQL, since you've lost all benefits of it.

There's several workarounds listed in this thread, that all do allow you to do this, basically with a single Client in urql. So, you can do this. But that doesn't mean it makes much sense.

The recommended way of using GraphQL, no matter whether you're consuming a third-party GraphQL API or any other kind of API, is to treat it as such — as a third-party API — and map this over to your own schema. If you don't want to go through the effort of this, you could look up "schema stitching", which can help with this by simply adding to your own schema with another GraphQL API, which a lot of utilities support (GraphQL Tools has some notes on this)

[NotFounds]

You basically end up doing something on the front-end that negates all strengths of GraphQL. At this point and with this usage, it basically doesn't matter that you're using GraphQL, since you've lost all benefits of it.

Thank you for providing specific examples. I now understand the meaning of "But that doesn't mean it makes much sense."

The recommended way of using GraphQL, no matter whether you're consuming a third-party GraphQL API or any other kind of API, is to treat it as such — as a third-party API — and map this over to your own schema. If you don't want to go through the effort of this, you could look up "schema stitching", which can help with this by simply adding to your own schema with another GraphQL API, which a lot of utilities support (GraphQL Tools has some notes on this)

I'll consider mapping the schema and also look into the concept of schema stitching. Thank you.