Middleware resolvers #81
Conversation
There are action that we may want to perform for all (or almost all) resolvers in an app. Currently the only way to do that is to add this action to every resolver. Middleware resolvers allow us to instead centrally define both those actions and the resolvers to which they shouldn't apply. - Create the MiddlewareResolver class and its interface - Execute middleware resolvers in any resolver pipeline, before the actual resolver logic.
| /* If any of the keys in the resolver pipeline should be ignored, ignore the whole pipeline, | ||
| * making the middleware the no-op for this request. | ||
| * | ||
| */ |
There was a problem hiding this comment.
An example is authorization: we may want to restrict write operations to a given role by default, but allow some specific write operations to all roles.
| ).toEqual(3); | ||
| }); | ||
|
|
||
| it('run middlewares sequentially in order', async() => { |
There was a problem hiding this comment.
This test succeeds in isolation but fails when running with the others. The issue is improper cleanup of the graphql.resolverMiddlewares binding, but I don't fully understand it yet.
|
@afallou You may want to look a bit at what, if anything, the core GraphQL layer provides. I don't mind this approach so much as to block it, but I worry about coupling. We're layering a new middleware abstraction on top of our own resolver pipeline abstraction, which means we're going further and further in a direction that doesn't play nice with any other approach to writing resolvers. At the time I wrote the initial |
|
@jessemyers I looked through the changelog of |
|
It turns out that the state cleanup issue I'm seeing in one test comes from the fact that nodule-config's |
There are action that we may want to perform for all (or almost all) resolvers in an app.
Currently the only way to do that is to add this action to every resolver. Middleware resolvers allow us to instead centrally define both those actions and the resolvers to which they shouldn't apply.