Fork me on GitHub
#graphql
<
2017-07-05
>
hmaurer16:07:12

Hello. I’ve a quick question which I suspect is not specific to Lacinia, but my Clojure knowledge is too limited to know. Is it possible to auto-reload a Lacinia edn schema and resolvers when using lacinia-pedestal?

hmaurer16:07:25

I managed to do it by modifying the code of lacinia-pedestal, but not “out of the box”

hmaurer16:07:33

(without restarting the server, that is)

hlship17:07:17

I don't have a specific way of reloading the schema; in general, our tests start up an entire system, run some HTTP requests through it, and shut it back down. In a live REPL, this is more than fast enough. However, I'm open to suggestions about what a better workflow would be for iterative development of the GraphQL schema ... which makes a lot of sense, given the existence of GraphIQL (i.e., the GraphQL REPL).

hlship17:07:32

Perhaps we could change lacinia-pedestal to place the compiled schema into the request with a well-known key. That would support a development mode option that would rebuild the compiled schema on each request. I'm just a little adverse to introducing changes with performance impact but little or no benefit, so discussion is needed.

hmaurer18:07:10

hlship: I have opened a (very small) PR related to this: https://github.com/walmartlabs/lacinia-pedestal/pull/13

hmaurer18:07:56

@hlship that’s what I was thinking. It would make it easier to pass a new schema. As a quick hack I just stored the compiled schema in an atom which I dereference in the interceptor, but passing it in the request context would be the “clean” solution it seems.

hmaurer18:07:40

Would it really impact performance? The compiled schema doesn’t have to be rebuilt on every request; that could be up to the developer to decide.

hmaurer18:07:24

Perhaps the pedestal-service function could take as parameter either a compiled schema or an interceptor. If it is a compiled schema it would add an interceptor in the chain setting that schema on the context under a known key, and if it is an interceptor it would add it to the chain, assuming that interceptor sets the right key on the request.

hmaurer18:07:38

I am not sure if that’s good design though, completely new to clojure/pedestal.

hmaurer18:07:42

It’s a fairly minor issue too as it took me 5mins to copy/paste lacinia-pedestal‘s code in my application and modify it to suit my needs

hmaurer18:07:37

Actually, it might be better for the pedestal-service function to take a function as a parameter which builds the GraphQL schema, which can then be called on every request.

hmaurer18:07:31

In that case you don’t even need to pass the compiled schema in the request context, and you keep the same performance if a compiled schema or constant function is passed.

hmaurer18:07:51

I’ll open a PR for this on lacinia-pedestal after testing it if you wish, and we can discuss it further there.

hmaurer19:07:17

@hlship now that I think of it, maybe it would also be nice to let :app-context be a function too (optionally). It would make it slightly more convenient to add authentication data to the context

hlship19:07:07

With that, it's just a matter of adding an interceptor to add to the context, based on authentication. I'm working to make the interceptor pipeline easier to extend.

hlship22:07:10

I've got stuff in a lacinia-pedestal branch that's all about making it easier to modify the interceptor chain, with ordering by dependencies. Coming some time after lacinia 0.19.0.

hmaurer22:07:31

That’s great. Should I open a PR this week for a small change to how the compiled schema is passed to the service?