chore(RFC): open core module system v1

[StarpTech]

Motivation and Context

Related work:

• chore(rfc): Extend core module system to support metrics #1130 (comment)
• chore(RFC): custom metric module system #1125

TODO

• Tests or benchmark included
• Documentation is changed or added on https://app.gitbook.com/
• PR title must follow conventional-commit-standard

[jensneuse]

A few goals I'd like to see covered:

• load my own config from my own config provider
• modify any config after load but before using it for a new mix
• allow the user to customize the transport (we're currently wrapping the default transport, let the user bring their own)
• hook into events like normalization, validation, parse (before, after)
• allow the user to define additional validation rules/steps
• Ideally, calling hooks is built in a way that automatically generates meaningful traces so that we're able to understand if and how much time the Router spends in a hook
• it should be easy to create a custom module / plugin as a go module which can then be imported and configured easily, making it simple to re-use and share custom extensions
• it would be nice if each module had it's own namespace (mandatory), like a prefix, so that the module can easily extend the existing Router config.yaml with it's own configuration without conflicts
• it should be possible to define custom authentication hooks
• it should be possible to define custom authorization hooks
• it should be possible to define custom rate limit hooks

Additional comments:
Should we call it Gateway or Router? We talk a lot about Router, should we stick to this convention?

I'll look more into the RFC and give more specific feedback later/tomorrow.

[davidhickeycbs]

I would suggest supporting the scenario where you only want to customize authentication but still use the built in authorization via directives (such as requiresScopes). For example, if I sign my JWT using an algorithm that Cosmo doesn't support, I would like to build a custom auth plugin that validates the JWT and injects the claims/scopes into the context, so that Cosmo can authorize access using the directives in the schema.

[janeli1]

Can we have add a GraphQLOperationPreParseHook? I am asking because I think we can use this new module system to implement Persisted Operations feature and PO fetching is done before parsing the operation.