Fork me on GitHub

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?


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


(without restarting the server, that is)


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).


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.


hlship: I have opened a (very small) PR related to this:


@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.


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.


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.


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


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


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.


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.


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


@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


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.


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.


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