You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to define gateway authentication and authorization as discussed in #343, we should add GraphQL hooks support to Mercurius so we can process data at different points in the request lifecycle.
Requirements
All necessary hooks triggered in Mercurius at the correct stage of the GraphQL request lifecycle
One can define multiple hooks of the same type where they run sequentially in the order of their definition
Make sure these hooks can be easily extended
Make sure these hooks are cleaned up correctly when needed (e.g. errors, timeouts)
Make sure just promises are supported
Documentation, TypeScript types and tests in Mercurius
Research and Exploration
Fastify currently uses hooks to allows users to define custom functionality at certain events within the codebase. You can define multiple hooks of the same name in this way. They are executed sequentially from the order at which they are defined.
Proposed solution
In Mercurius, we will add support for hooks by implementing core functionality also defined in Fastify. This will allow users of Mercurius and plugins to utilise the defined GraphQL lifecycle events. The hooks we will add will be:
preParsing: before queries are extracted from the input request. It will contain the following data:
MercuriusContext
Request
preValidation: before the queries are validated against the schema. It will contain the following data:
Extracted query data
MercuriusContext
Request
preExecution: this hook is triggered before queries are sent to the federated services (in the case of a gateway) or executing the query on the current GraphQL service. It will contain the following data:
Query AST(s) split by service
Destination schema AST(s) split by service
MercuriusContext
Request
preResolution: before the responses from each federated service or single service is crafted into a GraphQL response. It will contain the following data:
Response(s) split by service
MercuriusContext
Request
All new code with be 100% covered by tests and documentation will also be provided. The new hooks will be correctly typed. I have already started work on an implementation of this and will submit a PR for this once it is done and everyone is agreed on the solution :)
The text was updated successfully, but these errors were encountered:
Thanks for the long description, it's fantastic. SGTM with the plan, are you going to work on it?
A few notes: fastify supports both callbacks and promises. We should just support promises for this as the whole GraphQL ecosystem is all promise-based.
In order to define gateway authentication and authorization as discussed in #343, we should add GraphQL hooks support to Mercurius so we can process data at different points in the request lifecycle.
Requirements
Research and Exploration
Fastify currently uses hooks to allows users to define custom functionality at certain events within the codebase. You can define multiple hooks of the same name in this way. They are executed sequentially from the order at which they are defined.
Proposed solution
In Mercurius, we will add support for hooks by implementing core functionality also defined in Fastify. This will allow users of Mercurius and plugins to utilise the defined GraphQL lifecycle events. The hooks we will add will be:
preParsing
: before queries are extracted from the input request. It will contain the following data:preValidation
: before the queries are validated against the schema. It will contain the following data:preExecution
: this hook is triggered before queries are sent to the federated services (in the case of a gateway) or executing the query on the current GraphQL service. It will contain the following data:preResolution
: before the responses from each federated service or single service is crafted into a GraphQL response. It will contain the following data:All new code with be 100% covered by tests and documentation will also be provided. The new hooks will be correctly typed. I have already started work on an implementation of this and will submit a PR for this once it is done and everyone is agreed on the solution :)
The text was updated successfully, but these errors were encountered: