Fork me on GitHub
#graphql
<
2018-10-16
>
orestis13:10:26

Are there any drawbacks of making the resolvers look into their context for any component they need (e.g. a database) instead of (as the tutorial suggests) getting passed that dependency via a closure?

hlship16:10:12

It's situational and/or personal choice. The FieldResolver protocol was a later addition. Generally, if a field resolver is stand-alone (no dependencies, just a pure function), I prefer it to be a simple function; if it has component dependencies, I prefer it to be a component implementing FieldResolver. But at the same time, the application context exists specifically so that the outer application (typically, your Pedestal interceptor chain) can provide values that will be needed by field resolvers (or to allow outer field resolvers to provide data to inner field resolvers).

orestis17:10:45

Oh cool, I missed the field resolver protocol.

orestis13:10:41

I’d like (during development) to be able to re-eval a single resolver and have it have immediate effect, without actually having to re-eval some other things as well (e.g. my system).

sashton16:10:51

I do that by changing the resolver reference to #'my-resolver before starting my system. Then I can re-evaluate it.

orestis17:10:39

That works when the resolver is just a function, but not when it is constructed by closing over some stateful component, right?

sashton17:10:26

oh, sorry. i missed that context.

orestis18:10:07

Np :) that var trick is quite cool - and unless I misunderstand it, it’s a Clojure thing.

hlship18:10:28

I tend to use a workflow that will recompile the schema on each request. That's too slow for production and under load, but perfectly OK for interactive development and testing.

orestis18:10:30

Yes, we do the same! Now if only Graphiql would reload the schema :)