apollo-server
apollo-server copied to clipboard
Add Data and Variable types to executer operation
Previously created this PR https://github.com/apollographql/apollo-server/pull/6311 I don't seem to have the power to decline my old PR so when someone gets to this please decline it to avoid confusion
Was asked to move this to the version-4 branch and use a generic for GraphQLResponse rather than omit
Another comment was to use TypedDocumentNode I have no experience with this so can't quickly update the code to make use of this.
Reasoning
When using apollo-server-express to fulfil a rest request internally we are using the executeOperation to avoid HTTP and we want it strongly typed like our client side queries.
Rather than wrapping in a function to strictly type the variables and response of the query I've extended the function type to match how useQuery behaves in apollo-client.
Example usage
const gqlResponse = await apolloServer.executeOperation<
EventAllQuery,
EventAllQueryVariables
>(
{
query: gql`
query EventAll($eventId: String!) {
event(eventId: $eventId) {
... on AmericanFootballEvent {
id
name
eventStatus {
description
}
}
}
}
`,
variables: {
eventId: req.params.event_id,
},
},
{ req, res },
)
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Latest deployment of this branch, based on commit 94bc3e26bab7092d56430fe5a4a3493b063c4343:
| Sandbox | Source |
|---|---|
| Apollo Server Typescript | Configuration |
| Apollo Server | Configuration |
Thanks for reopening against v4 @jacksenior. I've added this to the v4 milestone, it'll be something we look at probably post-alpha. I like the idea!
I think this is a good idea and we should get it into AS4. We may want to make it work with TypedDocumentNode (and/or graphql-js' own somewhat unloved TypedQueryDocumentNode) as well. However, it involves changing the types of GraphQLResponse, and so will the work to make defer/stream work as part of AS4, so it's probably best to evaluate this after implementing incremental delivery (defer/stream).
I extended this into #6960. Thanks!