This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-27
Channels
- # aleph (7)
- # beginners (80)
- # boot (1)
- # cider (3)
- # cljs-dev (277)
- # cljsjs (52)
- # cljsrn (1)
- # clojure (69)
- # clojure-gamedev (4)
- # clojure-italy (1)
- # clojure-losangeles (2)
- # clojure-russia (89)
- # clojure-spec (92)
- # clojure-uk (196)
- # clojured (1)
- # clojurescript (70)
- # cursive (5)
- # data-science (1)
- # datascript (84)
- # datomic (9)
- # defnpodcast (12)
- # docker (1)
- # emacs (4)
- # events (1)
- # fulcro (112)
- # graphql (1)
- # jobs (1)
- # lumo (1)
- # nrepl (21)
- # off-topic (2)
- # onyx (3)
- # protorepl (10)
- # re-frame (23)
- # reagent (66)
- # reitit (2)
- # rum (13)
- # shadow-cljs (144)
- # spacemacs (14)
- # sql (4)
- # unrepl (29)
- # vim (16)
Does anyone have experience writing a GraphQL resolver that queries from Datomic (pull)? Is that pretty straightforward because of how pull works?
Depends on your authorization model and of the need for derived fields. I have set up a query server with similar semantics to graphql, and Datomic pull fell short for these reasons.
Custom caching logic and complementary data sources (e.g blob stores) can be other reasons why pull might be insufficient.
Oh and I forgot parameterized fields, of which pull has none either
So pull might be helpful locally, but I wouldn't count on it to just execute a whole GraphQL query.
If you're on a Peer and using Lacinia, I think expressing your resolvers in terms of the Entity API and occasionally Datalog is much less limiting.
Yeah, the entity API + lacinia work beautifully together