This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-15
Channels
- # announcements (8)
- # asami (10)
- # babashka (16)
- # beginners (86)
- # calva (22)
- # chlorine-clover (9)
- # circleci (20)
- # clj-kondo (13)
- # cljs-dev (20)
- # cljsrn (3)
- # clojure (144)
- # clojure-australia (10)
- # clojure-europe (126)
- # clojure-italy (5)
- # clojure-nl (8)
- # clojure-norway (4)
- # clojure-serbia (9)
- # clojure-uk (7)
- # clojurescript (14)
- # cursive (20)
- # data-science (1)
- # datomic (20)
- # figwheel-main (5)
- # fulcro (23)
- # graalvm (7)
- # graphql (25)
- # honeysql (15)
- # hugsql (3)
- # jobs (2)
- # lambdaisland (2)
- # leiningen (4)
- # lsp (102)
- # malli (3)
- # off-topic (51)
- # overtone (5)
- # pathom (27)
- # portal (11)
- # quil (1)
- # re-frame (19)
- # reagent (31)
- # remote-jobs (1)
- # reveal (3)
- # rewrite-clj (56)
- # shadow-cljs (45)
- # startup-in-a-month (1)
- # tools-deps (9)
Q: I am looking to implement a client side GQL API. this rules out Lacinia unfortunately. Looking for suggestions/ideas…
I can use interop and https://github.com/graphql/graphql-js but that rules out JVM SSR which would reduce some complexity for me
also considering https://github.com/wilkerlucio/pathom but it doesn’t support graphql resolvers. @U066U8JQJ any chance you plan to add this?
@U0510KXTU not sure what you mean by graphql resolver support, Pathom has a very distinct processing engine, and expectations there needs to be different from GraphQL, so I don't see it
there is GraphQL integration, but its a different thing, for that you need some graphql processor that already works
If its client side and this is something people have done, i'd imagine some JS lib exists
@U066U8JQJ since pathom resolvers are similar to graphql resolvers, I wondered if you had thought about supporting graphql by added a graphql->eql feature. I see you already support eql->graphql - hence the question
@U3JH98J4R yes, the graphql-js lib mentioned above is an example of that
no reason at all. I just prefer to use a clojure lib instead of interop because it makes testing the full stack much easier
@U0510KXTU GraphQL and EQL have the same goal of shape resolution, but Pathom resolvers are not like GraphQL resolvers, internally they are very different things (very different expectations). GraphQL is completly based (and depends on) a type system, Pathom approach is very different than that, I suggest you try Pathom for a while, and you can feel the difference yourself 🙂
its a design choice for Pathom to not have a upfront schema, and I believe to make something that looks like GraphQL we would need one, and that's a not for Pathom
thanks. I have used om.next previously and I’ve also played with pathom. I like the approach. that’s why I think it would be a great solution to my client side requirement
ah, ok. that clarifies it more. that’s a shame but I can see why you prefer schema-less
in theory, I could create a graphql->eql transform fn, even though the EQL layer doesn’t have a schema? I wonder if this would work?
I noticed pathom mentioned here too, hence the question https://book.fulcrologic.com/#_fulcro_and_graphql
https://github.com/oliyh/re-graph is a nice client, works both on the JVM, and in the browser, not necessarily with re-frame.
@U26FJ5FDM thanks but I need a gql server impl to run in the client in this case. I have used re-graph but these days I use https://github.com/r0man/grafeo because I prefer it’s terse DSL
@U0510KXTU I suggest you learn strait from Pathom 3 https://pathom3.wsscode.com/, the docs are better there, also better to understand the concepts
even if you use pathom 2 (the current, which is production grade tested, pathom 3 isnt)