Pass `extensions` to the client

[bsara]

Migrated from: apollographql/react-apollo#2059

[adamscybot]

Continuing coversation from apollographql/react-apollo#2059. I got around this by adding a link that overloads data with a function that returns the extensions.

// See https://github.com/apollographql/react-apollo/issues/2059
// Because of this we have to surface extensions via data to make them
// accessible downstream.
const ForwardExtensionsLink = new ApolloLink((operation, forward) => {
  return new Observable(observer => {
    const sub = forward(operation).subscribe({
      next: result => {
        result.data.extensions = () => result.extensions
        observer.next(result)
      },
      complete: observer.complete.bind(observer),
    })
    return () => {
      if (sub) sub.unsubscribe()
    }
  })
})

Then

    <Query
       ....
    >
      {result => {
        console.log(
          ' result',
          result.data && result.data.extensions && result.data.extensions()
        )
    <Query>

[sgrove]

We have a similar approach we've taken that's slightly less elegant (using a custom link + mutable state outside the request): https://github.com/OneGraph/onegraph-examples/compare/request-metrics

We wrote about the motivating case a bit as well

[nathanburgess]

In case anyone else comes across this thread: you can simply access error.graphQLErrors now.

const { error } = useQuery(SOME_QUERY)

if (error)
    console.log(error.graphQLErrors)

[Borvik]

@nathanburgess While correct you can access it via the errors, the problem is accessing the extensions when there isn't an error.

[nathanburgess]

@nathanburgess While correct you can access it via the errors, the problem is accessing the extensions when there isn't an error.

Ah, my bad, I misinterpreted the issue then.

[Borvik]

@Migushthe2nd Where did you see they are "moving away from extensions"?

As far as I can tell they are deprecating the graphl-extensions in favor of a Plugin system. Doesn't mean this extension in the response, which is what this is all referring to, will be going away.

[Migushthe2nd]

@Borvik I might have mixed up some some terms, probably because I can't find a good overview. I'd appreciate it if you could help answer a few questions :)

1. So this graphql-extensions, what does it do? I can't find any documentation on it (anymore).
2. What is the difference between graphl-extensions and the new Plugin system?
3. What is the difference between GraphQL's extensions and Apollo Server's extensions?
4. What is the extensions field in ApolloServer used for?

[Borvik]

Not sure I can fully answer that, but I'll give it a shot (barely got my feet wet with either).

graphql-extensions was I believe an informal (as in not a formalized spec for how apollo-server should work) for extending the server functionality by adding. It allowed tapping into various points of the request lifecycle, such as before the resolvers, after the resolvers, on startup - just before the response to the client. Without the docs I can't be sure of exactly which points it allowed hitting.

The new Plugin system - does the same thing, it's just a slightly different format, and formalized it making it no longer "experimental". See https://www.apollographql.com/docs/apollo-server/integrations/plugins/

Not 100% sure what you mean with 3, but the only extensions I am aware of as part of the GraphQL spec deal with the schema and extending (inheriting) types.

As far as the extensions field, I'm assuming you mean what is sent in the response. I don't know if that's an apollo spec, or GraphQL spec, but it just a way of returning extra data not part of the main query/mutation being run. Incidental things, like apollo-tracing providing performance metrics of the queries.

[Borvik]

Incidentally I just looked at your linked issue for vue-apollo, and that is one of the main reasons I have looked into it - pagination data. Didn't want to bloat the types with pagination stuff.

Other scenarios - alerts. I've got something set up for the server to log an alert (success, warn, info, error) that will cause a toast to show on the client. It works in some scenarios, but not all - because extensions get filtered in some cases.

Another scenario - permission lists. Really in a query it would be nice to pass a permission list of permissible actions for a given object/page. This permission list could help drive the UI of a client, and doesn't really belong in the type (say a Product) as it doesn't really belong to the Product but rather the permissions of the logged in user of what they may do with any Product (vs a specific product - like is_locked, which indeed would belong on the type).

[Migushthe2nd]

Those three cases you're talking about, do you use vue-apollo in their project(s)? I'm asking since I don't think this is an apollographql issue anymore, because of #117 (comment). From what I have tested the vue-apollo module seems to be the cause and I think it's better to continue discussion there (vuejs/apollo#1018) if you don't mind.

[Borvik]

Actually I don't use vue-apollo - I use react-apollo.

If I remember tracing it properly, I think it actually traced back to apollo-client

[Migushthe2nd]

Oh you you did (unlike me)? I'll have a look at it tomorrow. Thanks!