This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-30
Channels
- # aleph (2)
- # announcements (4)
- # babashka (3)
- # beginners (89)
- # calva (12)
- # cljdoc (7)
- # cljsrn (5)
- # clojars (1)
- # clojure (19)
- # clojure-dev (6)
- # clojure-europe (2)
- # clojurescript (12)
- # conjure (7)
- # cursive (4)
- # fulcro (28)
- # graphql (6)
- # gratitude (2)
- # introduce-yourself (2)
- # jobs (1)
- # jobs-discuss (26)
- # off-topic (2)
- # pathom (22)
- # pedestal (2)
- # podcasts-discuss (10)
- # re-frame (9)
- # reitit (8)
- # releases (2)
- # remote-jobs (1)
- # shadow-cljs (1)
- # tools-deps (27)
- # xtdb (11)
I haven't tried out pathom 3 yet. the talk you gave @wilkerlucio made the remote resolver look awesome. if I'm exposing a pathom API over HTTP, is there anything different that my consumers will need to do if/when I move to pathom 3?
that part of the external interface is fully compatible, ita about changing the engine, but the interface for clients remains the same, pathom3 does extend it tought, on top of the eql request (that takes the vector form) there is also the new map format, the intention is to allow more than just the query, like data for the root entity
(the map format is provide by what I call boundary interface in pathom3)
that's great. i'll look in the docs for the map format, as i'll want to at least think about how to add support for it later
I understand the implementation of the parser et al. is very different. we are making use of pathom2 now and starting to build some client-side tools around it and I'd like to ensure those tools are future proof. atm they basically boil down to "submit an EQL query via POST" and it seems like it wouldn't be different with pathom3
hey @wilkerlucio 🙂 a SUPER common situation we have is we're pulling data out of the db on the server, and then shipping that plus some env to the client, and then composing + deriving a bunch of stuff for a react app to render / make interactable. it seems that we could rewrite a lot of this as resolvers in cljc, and then somehow use them on both sides of the wire - so that when we need that composition / derivation on the server, it's there, but when we use it on the client, it fetches the stuff that only the server can provide, using the distributed computing mode you demonstrated. that's Thing One. Thing Two is, wrapping the server's impl in an access control layer. if you're allowed, you get the data, but if you're not, you get an error. secondly, if you're allowed, the data you get is based on who you are (think social graph). is there perhaps a working example somewhere, showing pathom3 on both the client and the server, in cljs + clj respectively, doing that distributed example in your London talk, on which i could experiment to get a spike of all of this going?
@U0509NKGK i’m curious: do you (and also looking for other people) often run pathom on both the client and server?
in my head it seems like pathom on the client would be a lot of additional overhead but maybe I just don’t understand how the client-server integration could work
i've never used pathom before
just thinking about how i'd like to try to use it!
we basically use it like GraphQL atm. send queries get data back. cache them in a normalized store
I'm planning to write such demo soon, its quite similar to the one I did on the presentation, the major difference is to also make the proper setup on the CLJS side (regading transit encoding)
one other architecture I see is also adding web workers to this game, so you may have 3 pathom systems going on, one at the UI level, one at worker level and one at server level
@wilkerlucio i'm pretty keen to get this working so if i can assist, lemme know
thanks, that's very welcome, specially the testing part, this is a part of the pathom with little exercising at this time, so I consider experimental stage from it, but the best way I see to get it to a reliable solution is to try it out and find the rough edges 🙂
i'm also a Datomic on-prem user, so keen to do this with your datomic spike too 🙂
for the datomic, altough there is a going on attempt (https://github.com/wilkerlucio/pathom3-datomic) to make everything as automated as possible, IME there is also the problem of controlling/security, unless you are writing a database manager (or something else supposed to have full access) it seems like having specific smaller implementations (in specific resolvers) is better to handle environments with tighter access control needs
yep. a large part of our domain deals directly with this aspect of things. i'd really love to build out a set of resolvers that model this on top of what you're doing there
i can see P3 removing tons of code here 😄
(seems my questions are similar to lilac's)