The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.
It seems good to just union all of the extensions fields from remotes and (if any) from hasura. The only trouble obviously is when names overlap or the client needs to disambiguate extension responses from different remotes used in same query.
We could return our own extensions where we put remote extensions under separate namespaces. But that might entail rewriting clients which might defeat the purpose...
This came up here: https://github.com/hasura/graphql-engine/issues/2432
https://graphql.github.io/graphql-spec/June2018/#sec-Response-Format
It seems good to just union all of the
extensions
fields from remotes and (if any) from hasura. The only trouble obviously is when names overlap or the client needs to disambiguateextension
responses from different remotes used in same query.We could return our own
extensions
where we put remoteextensions
under separate namespaces. But that might entail rewriting clients which might defeat the purpose...