This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-13
Channels
- # bangalore-clj (1)
- # beginners (40)
- # boot (22)
- # clara (19)
- # cljs-dev (265)
- # clojure (160)
- # clojure-dev (6)
- # clojure-italy (5)
- # clojure-russia (47)
- # clojure-spec (10)
- # clojure-uk (63)
- # clojurescript (88)
- # core-async (8)
- # cursive (54)
- # datomic (48)
- # emacs (32)
- # garden (3)
- # graphql (29)
- # hoplon (54)
- # jobs (1)
- # klipse (4)
- # luminus (5)
- # lumo (21)
- # mount (5)
- # off-topic (16)
- # om (2)
- # pedestal (10)
- # play-clj (1)
- # portkey (32)
- # re-frame (21)
- # reagent (48)
- # rum (1)
- # spacemacs (4)
- # sql (3)
- # unrepl (5)
Curious about the state of graphql in clojure. How mature are the clojure graphql implementations? Which one is the most mature, is anyone using it in production? And how easy is it to optimize the query-building/planning… I don’t know much about graphql, but I gather that’s what dataloader does? Do anyone of the clojure APIs support this?
Similarly are the java implementations mature, and is it perhaps better to use one of those just now?
@rickmoynihan graphql-java is terrible. We're using it in production but our use predates Lacinia. We're planning on switching to Lacinia when time permits. If anything, it appears to me that Lacinia is more mature than graphql-java.
@domkm: interesting… Id’ve thought a java implementation would’ve been more mature at this stage
I really don’t know much about graphql though
is it possible to optimise the requests to the backend? For the data we plan to use it for, I suspect if we didn’t it’d be far too slow and result in way too many requests
Please give the Lacinia documentation a skim; we've worked hard on it, and it answers your questions.
specifically the N+1 query problem
there's urania that looks interesting (https://github.com/funcool/urania), although I haven't tried it out. Inspired by https://github.com/kachayev/muse and Haxl/Stitch
graphql-java and Lacinia should be similar in this respect with a slight edge given to Lacinia because it exposes more of the query data to resolvers
Look into https://github.com/alumbra/alumbra if data batching is a primary concern. I can't speak to its completeness or maturity, though.
wow ok, lots of different bits and pieces… not sure how easy it is to evaluate the viability of this. Am I right that the two main clojure implementations of graphql are: - lacinia - alumbra ? How do they compare in completeness to the spec/js-reference-implementation? And project longevity?
Lacinia is used by Walmart and seems like the primary implementation currently. Alumbra focuses on data access. It seems cool (though complicated) and I don't know the state of the project. There's also https://github.com/tendant/graphql-clj which was not feature complete but may be now; I haven't kept track.
@domkm: > Lacinia is used by Walmart Sounds like it might be quite mature then… Do we know what they’re using it for? I note that it’s from wallmartlabs, so is it experimental? Do they just use it for some small backend system, or to power critical infrastructure?
WalmartLabs is just a clever name for Walmart's E-Commerce division. If you use the Walmart app on iOS or Android, or many of your requests are now routed through Lacinia. There are also other systems, related to grocery orders, built entirely in Lacinia. So, yes, Lacinia is mature and production capable.
see their Clojure/west talk: https://www.youtube.com/watch?v=I0vVkQfmy9w
We also discuss our use of GraphQL here: https://www.youtube.com/watch?v=tHQAMrShHu8&t=777s
thanks
Claro, Muse and Haxl look really interesting… Claro claims to be inspired by Muse… Does anyone know why it was created though? Why write a different library for the same thing? What was perceived to be deficient in muse?