Add middlewares to implement customizable logic around different stages of query execution

[chedom]

Add middlewares to implement customizable logic around different stages of query execution.

Use cases:

• Distributed tracing
• Gathering metrics (rate/duration per query, in-flight queries, etc)
• Custom logic before/after query execution (action log, field authorization, etc)

For that purpose I propose to add next middlewares:

• OperationMiddleware
• RootFieldMiddleware
• FieldMiddleware
• ResponseMiddleware

These middlewares are used in gqlgen.

If this approach is not valid could you advise how to inject custom logic before different stages of query execution ?

If proposed approach is valid I could reopen PR #284 (and add one more with RootFieldMiddleware).

[jensneuse]

Hey, I'm glad you're back. I hope you're ok. As you might know, we've got 2 Ukrainian employees. Let me know if we can support you in any way.

Regarding the PR, we'll look at it next week. The description seems promising. We're currently also working on OTEL in WunderGraph, so this might be great timing.

[chedom]

Thank you for your attention to this matter!

We launched our federation over a year ago and now it consists of more than 20 subgraphs (and this is not the end). Our federation is based on the fork (there is lack of tests and some code smells because of deadline) and I really want to incorporate some features and bug fixes into upstream and switch our federation from fork to the upstream.
Fork is outdated and some features have already been implemented in the upstream (like websocket init function, some bugs (deadlocks, race conditions) in ws client).

[lachlan-smith]

OTEL/middleware is something we are currently on the hunt for and this implementation looks promising for our use case.

We have currently forked and re-added chedom's OperationMiddleware code to trial the functionality, but would be good to get some more insight on how wundergraph plan to implement OTEL and if it would be making it's way to the graphql-go-tools package as well.

[jensneuse]

We've implemented OTEL ourselves by simply instrumenting the HTTP transport. This way, we didn't have to make any changes to the "engine" itself.