Implement FieldMiddleware Stack #221
Conversation
codegen/directive.go
Outdated
| } | ||
|
|
||
| func (d *Directive) Name() string { | ||
| return strings.Title(d.name) | ||
| func (d *Directive) GoName() string { |
There was a problem hiding this comment.
maybe this should be NameUpper? where is this used?
There was a problem hiding this comment.
also, https://github.com/vektah/gqlgen/blob/master/codegen/templates/templates.go#L65 is available in templates
mathewbyrne
changed the title
This will allow us to include DirectiveMiddleware in the same middleware setup, that will run after Resolver middlewares.
We need the Field Definition so that we can run directive middlewares for this field.
Moves it off of RequestContext and into generated land. This change has a basic implementation of how directive middlewares might work.
mathewbyrne
force-pushed
the
middleware-stack
branch
from
2d58041 to
0ec918b
Compare
|
@mathewbyrne @vektah can we get HTTP headers value in field middlewares as mostly auth details are passed as HTTP Headers? |
|
@ridhamzuru you have access to |
|
@mathewbyrne Are we talking about graphql This is what I get in the context variable so still can't access the HTTP variables |
|
Right, context doesn't have the HTTP data you're after on it directly. What I was getting at was that you should do authentication as a middleware, then use context to pass down relevant data (e.g. authenticated user id) to resolvers throughout your graph. This has come up a few times now (#262), so we will look at getting some examples together for how we recommend doing this. |
|
But how can I get the name of query or mutation in |
|
It sounds like you might be mixing up your authentication and authorisation logic. Authentication should not need information about the query to happen. Once you have authenticated through whatever scheme you're using, you can make authorisation decisions at the resolver level using a directive. |
|
Can we one simple example for JWT with recommended way? Even small gist will do the work with server file and handler. |
|
@mathewbyrne I have implemented with context suggestion and commented on #262 |
Implement FieldMiddleware Stack
Following on from #217 this change introduces a the concept of DirectiveMiddleware to generated code.
A
DirectiveRootstruct is now created and can be passed in when creating an executable schema. If a directive is encountered during codegen from the source schema, thisDirectiveRootwill contain a field for each that the user can assign. Each field has the same signature as aResolverMiddleware, and is run on fields with this directive at the end of the resolver middleware chain.Within the directive middleware, users can access the current request and resolver contexts, and can either call the next middleware in the chain, or return a value early.
Limitations
gqlgenandgqlparser.NewExecutableSchema, and the config that can be provided toGraphQL.DirectiveRootis implemented as a struct, but this could easily also be an interface instead. Current thinking is that a struct allows a user to get up and running without having to implement their directives immediately; they are noops until set.