This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-10
Channels
- # announcements (6)
- # architecture (2)
- # babashka (30)
- # beginners (90)
- # calva (21)
- # cider (22)
- # clj-kondo (27)
- # cljs-dev (7)
- # clojure (132)
- # clojure-europe (51)
- # clojure-nl (12)
- # clojure-norway (3)
- # clojure-spec (3)
- # clojure-uk (5)
- # clojurescript (69)
- # cloverage (9)
- # conjure (5)
- # core-async (54)
- # cursive (14)
- # datomic (34)
- # emacs (7)
- # fulcro (10)
- # graalvm (40)
- # graalvm-mobile (2)
- # gratitude (2)
- # improve-getting-started (1)
- # introduce-yourself (1)
- # jobs-discuss (61)
- # leiningen (5)
- # malli (6)
- # off-topic (59)
- # pathom (11)
- # polylith (38)
- # reagent (3)
- # reitit (3)
- # rewrite-clj (3)
- # shadow-cljs (53)
- # tools-build (35)
- # transit (8)
- # vim (62)
- # web-security (26)
- # xtdb (4)
Hi all! I’m investigating whether we want to start using Pathom. I’ve read some documentation, seen videos, and listened to the podcast episodes with Jacek Schae. I’m sold on the concept, no worries there 🙂 I guess from what I’m reading here that we should stick with Pathom 2 for now, as this is an existing production system. There is one area that I’m not clear about: the client-server story. I’m envisioning a situation where our (ClojureScript/react) client uses Pathom to get its data from our (Clojure/Ring) server. Suppose I start doing that, I will have to build a lot of resolvers on the server and I can of course start using Pathom server-side. But how do I use those same resolvers from the client? I guess that I would need the same set of resolvers in terms of input and output specification, but instead of going to the database, they have to go to our backend. How is this supposed to work? Am I missing some part? Even better, is there maybe an example of such a setup somewhere? Many thanks for your thoughts!
Hey @UGNFXV1FA 👋 Happy to hear you’re sold on the concept! AFAIU the idea for client-server communication is that the client sends EQL query over to server which handles the request using pathom parser to resolve the query and return the response data. The most popular pathom setup is its integration with fulcro and you can see how it all works together in https://github.com/fulcrologic/fulcro-rad-demo. Granted you don’t need to adopt the entire framework to use pathom, you can still take a look at fulcro’s code to see how this client-server communication is set up there. Here are some pointers: • https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/networking/http_remote.cljs#L356 to the server (there’s a lot more going on there, but https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/application.cljc#L90) • server uses ring https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/src/shared/com/example/components/ring_middleware.clj#L37-L38`/api` handler which passes the query to the https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/src/xtdb/com/example/components/parser.clj#L33 There’s a lot of fulcro and fulcro-rad convenience wrapping around all of it, but if you follow the trail and skip what you don’t need, the basic idea is simple.
Thanks for the pointers Piotr; indeed I was not planning on switching to fulcro, but I will definitely investigate the pointers that you gave, I’m sure that will help!
So unless you have something very specific that is only supported in pathom2 i would stick with pathom3
I would advocate for pathom3 as well I had some problems with pathom2 and nested batched resolvers, those problems are solved in pathom3 now
I'll throw my two cents in: We've been using pathom3 for several months. We have not had any major problems.
hello @UGNFXV1FA, at this point I also suggest starting with Pathom 3, performance is better and it has more features, in terms of stability, the basic features are stable, the parts that I don't consider stable are: • parallel process: feel free to try, but keep in mind the chances of erros are higher, that said I always appreciate bug reports so we can start closing the gap • distributed process: that's a feature you can connect multiple Pathom instances in a federated way, this is a killer feature that I want to get more stable, this allows you for example to have one pathom running on the server, and another instance running on the client, so the client connects to the server (supporting everything there) while is also capable of adding its own resolvers that will run in the client side, no current known bugs but I feel it needs more usage to find problems (specially when combining more complicated features like optional inputs and nested inputs)
a heads up that goes for also everybody else here, I've been working to improve the error handling in the strict mode (so we can render partial complete plans on Pathom Viz for example), this will cause minor breaks on the internals (I believe no user will be affected by those), and one that may affect you all is a change I'm thinking for the boundary interface, I want to change it to never throw (even on strict mode), instead it should return an error in a data format, I'm going over this because sending exceptions over the wire is a pain and I think a data format will smooth things out
I love this idea - I'm particularly happy that partial plans will be available in the vizualizer
That's great feedback from all of you, awesome! I guess it will be Pathom 3 then, I'm glad it's already stable enough! And @U066U8JQJ it sounds like that federation is what I was hoping for, sounds great! 😀
a heads up that goes for also everybody else here, I've been working to improve the error handling in the strict mode (so we can render partial complete plans on Pathom Viz for example), this will cause minor breaks on the internals (I believe no user will be affected by those), and one that may affect you all is a change I'm thinking for the boundary interface, I want to change it to never throw (even on strict mode), instead it should return an error in a data format, I'm going over this because sending exceptions over the wire is a pain and I think a data format will smooth things out