This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-05
Channels
- # bangalore-clj (1)
- # beginners (50)
- # boot (72)
- # cider (53)
- # cljs-dev (303)
- # cljsrn (2)
- # clojure (403)
- # clojure-conj (3)
- # clojure-dev (7)
- # clojure-italy (18)
- # clojure-russia (129)
- # clojure-sg (1)
- # clojure-spec (44)
- # clojure-uk (25)
- # clojurescript (112)
- # core-async (4)
- # core-typed (3)
- # cursive (23)
- # datomic (114)
- # defnpodcast (1)
- # emacs (1)
- # figwheel (2)
- # graphql (18)
- # hoplon (110)
- # instaparse (6)
- # jobs (3)
- # jobs-discuss (10)
- # leiningen (5)
- # luminus (1)
- # lumo (151)
- # off-topic (22)
- # om (3)
- # om-next (3)
- # onyx (4)
- # parinfer (1)
- # pedestal (8)
- # precept (51)
- # re-frame (19)
- # reagent (3)
- # ring (1)
- # ring-swagger (5)
- # spacemacs (21)
- # sql (25)
- # test-check (2)
- # uncomplicate (8)
- # unrepl (33)
- # untangled (20)
- # yada (14)
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”
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: https://github.com/walmartlabs/lacinia-pedestal/pull/13
@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.
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.