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.

[kaialang]

Will user be able to use GraphQLOperationPlanHook for monitoring the planCache or a separate GraphqlOperationPlanCacheHook is needed? It could be useful for monitoring the cache hit/miss and maybe even modify the caching policy based on their needs.

[StarpTech]

That is a possible way. The current direction is to provide additional information in the context e.g. if a plan was fetched from the cache could be on the context of the PostGraphQLOperationPlanHook

[kaialang]

For custom metrics, what's the plan for users to measure end-to-end latency of a request? Maybe something like the following? Do we have any concerns on context propagation throughout the entire request lifecycle? In case of early exit or errors, OnRouterResponse never get called, we lose those latency metrics.
func (m *MyTallyModule) OnRouterRequest(req *core.RouterRequest, err error) error {
req.Context = context.WithValue(req.Context, startTimeKey, time.Now())
return nil
}

func (m *MyTallyModule) OnRouterResponse(res *core.RouterResponse, err error) error {
startTime, ok := res.Context.Value(startTimeKey).(time.Time)
if !ok {
return nil
}

latency := time.Since(startTime)
timer := m.TallyScope.Timer("request_latency")
timer.Record(latency)

return nil

}

[kaialang]

Now I think about it, my solution has the assumption of OnRouterRequest is "PreRouterRequest". Without knowing exact point on OnRouteRequest, this may or may not work.

[flymedllva]

Currently, we are using Content() from OperationContext. How to get it in the new version?

[StarpTech]

Good question. This RFC tries to approach the overall picture of the system. Everything what was possible in the old system must be possible in the new system just in a different way. The original and normalized query will be available on the operation object as well.

[flymedllva]

How to use request *http.Request? In the current version we make headers propagation ourselves without using router configs, we also add custom headers.

The same applies to subgraph responses.

Plus to avoid getting a race we put a mutex in the context and use it when changing req/resp

[flymedllva]

I'm not sure how to use it yet. I would like to be able to replace the status code in the subgraph responses, to decide which are good and which are not, which should be retrained and which should not. And then modify the router's final response after gluing and downloading everything

[flymedllva]

This interface will have to be driven to your error type somehow? Or how to change it?

[flymedllva]

It seems that what I described will be done in OnRouterResponse https://github.com/wundergraph/cosmo/pull/1063/files#r1778364936? And this method will be triggered after OnRouterResponse?

[kaialang]

I see OnSpan() and OnMetric() can be useful in some cases. But adding attributes can be achieved by adding keyValue pairs in request context (please correct me if I'm wrong).

This is a different level of abstraction. I would strongly prefer a more flexible hook system, eg, using Pre/Post, that allows to metric/tracing plugins. We can still provide default Prometheus, OTel metrics/tracings by building default plugins on top of the hook system.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[StarpTech]

Closed accidentally from bot

[flymedllva]

1.1 We are interested in changing the message, as I understand we will now have this access.
1.2 It is not clear how we will work with untyped extensions, through fastjson? It's important for us not to change custom extensions that we didn't expect.
2. We would also like to understand which subgraph the error belongs to, so that we can change it with this logic in mind. Let's say the status code returned a subgraph
3. We want to do ctx.Set, so that we can get the modified errors in other methods (for example, for logging).

[flymedllva]

Somewhere in here I wanted to be able to get

	Id string
	Name string
	Url *url.URL
	UrlString string
}

So that this information can be used when changing the error.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[ghorak-happening]

Hi,

Great stuff here. One thing that I didn't see is the possibility to hook into the EDFS lifecycle.
Would it be possible with the Custom Module System to intercept subscription requests to subgraphs and inject a custom transport, similar to the Kafka or NATS that you already provide.

I would be particularly interested in adding Redis PubSub support to EDFS.

Thx,
Goran

[StarpTech]

Hi @ghorak-happening, that's a great idea. The goal of this RFC is to propose an architecture that is flexible enough to add those extensions later. The first version will focus on the fundamentals. I'm going to add your requirements to the list so as not to forget them.

[ghorak-happening]

That would be great @StarpTech, thank you!

[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.