wundergraph
chore(RFC): open core module system v1
Motivation and Context
Related work:
- https://github.com/wundergraph/cosmo/pull/1130#issuecomment-2452872727
- https://github.com/wundergraph/cosmo/pull/1125
TODO
- [ ] Tests or benchmark included
- [ ] Documentation is changed or added on https://app.gitbook.com/
- [ ] PR title must follow conventional-commit-standard
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.
A few goals I'd like to see covered:
@jensneuse Please take a closer look to the proposal. Most of your points has been already addressed. For other points, I do miss a real world use case e.g
allow the user to customize the transport ...
The goal of the module system is to enable all sorts of use cases, but we need to be very careful not to expose internals where developers can shoot themselves in the foot.
Other points are valid though and I'm going to address them. Thank you.
A few goals I'd like to see covered:
@jensneuse Please take a closer look to the proposal. Most of your points has been already addressed. For other points, I do miss a real world use case e.g
allow the user to customize the transport ...
The goal of the module system is to enable all sorts of use cases, but we need to be very careful not to expose internals where developers can shoot themselves in the foot.
Other points are valid though and I'm going to address them. Thank you.
Some companies want to have full control over the transport. I'd leverage our existing transport architecture, but allow them to override the wrapped transport if they want to. It's a potential risk, sure, but in such a case they will know what they do.
This PR was marked stale due to lack of activity. It will be closed in 14 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Closed as inactive. Feel free to reopen if this PR is still being worked on.
This PR was marked stale due to lack of activity. It will be closed in 14 days.
This PR was marked stale due to lack of activity. It will be closed in 14 days.
Closed as inactive. Feel free to reopen if this PR is still being worked on.
Closed in favor of the ADR https://github.com/wundergraph/cosmo/pull/1863