Redwood: [RFC] Bring your own GraphQL library

Created on 10 Sep 2020  路  5Comments  路  Source: redwoodjs/redwood

Right now Redwood ships with Apollo's GraphQL client out of the box. We don't know if that will change, but we would love to give you the ability to switch to the GraphQL client of your preference.

As a user, nothing will change if you're happy with the GraphQL client! This is only for people who would want to change the client.

How does this work right now?

Right now we initialise the Apollo GraphQL library in <RedwoodProvider> where we do two things:

  1. We grab the API_PROXY_PATH value from the redwood.toml configuration to point to the URL to your GraphQL server.
  2. We determine if you're users are authenticated and we put the appropriate Authorization headers into the GraphQL clients configuration.

How would you specify your own GraphQL client?

// ./web/src/index.js
return (
  <AuthProvider>
    <RedwoodProvider 
        graphQLClient={({ url, headers }) => new GraphQLClient(url, { headers })}
        queryHandler={({ query, variables }) => useQuery(query, { variables })}
    >
    </RedwoodProvider>
  </AuthProvider>
)

We would provide the url to your GraphQL server and headers to facilitate authentication, which you would pass to the configuration of your client. You would also need to let us know how to run run queries.

Let me know what you think!

kindiscussion

Most helpful comment

I think it's largely subjective, but maybe bundle size and simplicity are _really_ important to your particular use case and you don't need something as heavy as Apollo.

So, the main reason for this is to consider is that we used Apollo v2 and it took us several weeks to upgrade to v3. You might decide that there are features that are important for you and you don't want to be trapped into whatever Redwood decides. Alternatively you might decide that you actually want to stay on v2 and don't want to upgrade to v3 just yet.

All 5 comments

Wow, PP, admittedly when you first floated this idea I was 馃槵. But this is very elegant.

Definitely 馃憤

what would the benefits be to replace apollo with something like urql if you wanted to?

https://github.com/FormidableLabs/urql

I think it's largely subjective, but maybe bundle size and simplicity are _really_ important to your particular use case and you don't need something as heavy as Apollo.

So, the main reason for this is to consider is that we used Apollo v2 and it took us several weeks to upgrade to v3. You might decide that there are features that are important for you and you don't want to be trapped into whatever Redwood decides. Alternatively you might decide that you actually want to stay on v2 and don't want to upgrade to v3 just yet.

@peterp Do we need to add a similar syntax for the tests to tell them what to use for mocking? Does the mock stuff we do now depend on Apollo behind the scenes or is it more generic?

@cannikin Ah, I thought I responded to this. The tests and storybook will all continue to work as mock service worker is indy from the client.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CR1AT0RS picture CR1AT0RS  路  4Comments

thedavidprice picture thedavidprice  路  3Comments

balaji-balu picture balaji-balu  路  3Comments

zwl1619 picture zwl1619  路  3Comments

weaversam8 picture weaversam8  路  3Comments