This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-24
Channels
- # architecture (7)
- # beginners (73)
- # boot (4)
- # cider (48)
- # cljsjs (7)
- # cljsrn (27)
- # clojure (206)
- # clojure-boston (2)
- # clojure-italy (21)
- # clojure-nl (8)
- # clojure-spec (7)
- # clojure-uk (94)
- # clojurescript (126)
- # clojutre (7)
- # core-async (3)
- # cursive (7)
- # data-science (1)
- # datascript (4)
- # datomic (6)
- # duct (1)
- # emacs (19)
- # figwheel (1)
- # fulcro (31)
- # graphql (13)
- # jobs (5)
- # jobs-discuss (42)
- # keechma (4)
- # leiningen (10)
- # luminus (3)
- # mount (2)
- # nyc (3)
- # off-topic (37)
- # om-next (3)
- # onyx (45)
- # pedestal (2)
- # re-frame (4)
- # reagent (2)
- # reitit (16)
- # shadow-cljs (118)
- # spacemacs (10)
- # tools-deps (8)
- # vim (20)
Hmm. So it seems we can only parallelize different attributes for an entity, and not different entities.
Well that still doesn't allow lacinia to parallelize more-inner attributes,though. Hrmm.
It will be able to do parallel work once the entire list of entities are resolved as a chunk.
It might be possible to do this BUT we're hitting issue describing the output of a resolver function (both in terms of type signature or equivalent in code, and in terms of user facing documentation). I've been down the route (see Tapestry) of creating really concise, useful magic ... but then being unable to describe the sequence of events and operations that occur at runtime.
I think I can solve this problem external to lacinia with an LRU cache of sorts, actually.
Right; if Lacinia does too much, it starts to get in the way and prevent certain solutions, or violate the principle of least surprise.