This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-21
Channels
- # bangalore-clj (11)
- # beginners (82)
- # boot (1)
- # braveandtrue (29)
- # cider (16)
- # cljdoc (2)
- # cljs-dev (2)
- # clojure (74)
- # clojure-dev (3)
- # clojure-italy (2)
- # clojure-mke (1)
- # clojure-nl (4)
- # clojure-sg (1)
- # clojure-spec (1)
- # clojure-uk (53)
- # clojure-ukraine (1)
- # clojurescript (33)
- # cursive (29)
- # datomic (59)
- # editors (4)
- # emacs (14)
- # fulcro (2)
- # graphql (12)
- # hoplon (2)
- # nyc (4)
- # onyx (5)
- # parinfer (10)
- # pedestal (22)
- # re-frame (11)
- # reagent (35)
- # ring-swagger (5)
- # shadow-cljs (150)
- # tools-deps (9)
- # vim (1)
- # yada (20)
Does lacinia support parameterized queries? And if so, is it possible to hook into the library in such a way that I can cache backend queries?
What I want to do is reuse queries when only the parameters change from one GraphQL query to the next.
I find that question kind of confusing, maybe I am having a hard time determining what query is referring to in context (graphql query, backend query?)
a particular resolver will be called, and it can be a stateful thing that keeps any kind of of cache you want
@hiredman GraphQL supports "stored procedures" of a sort: https://graphql.org/learn/queries/#variables
The Java GraphQL API uses this to only perform parsing/validation when the query string is un-cached.
Agreed, but in my case they do, I want to push that down into my query logic. There's some optimizations and complex logic happening in my data fetchers and I'd love to be able to re-use those
I think you could do that, because it is possible to parse a query separately from executing it (so you could cache the parse step) and you could push that information down in to the resolvers using the context
but it seems like it would be better to have the resolvers cache whatever based on the args?
That's a good point, I'll think it over a bit