Fork me on GitHub
#pathom
<
2021-02-27
>
prnc09:02:27

Hello 👋 what is the current pathom (esp. pathom3) + datomic story? I would love to give pathom a go and I’m looking for pointer re: a good place to start i.e. earn about using it with datomic. Is https://github.com/wilkerlucio/pathom-datomic something one can use with pathom3?

wilkerlucio11:02:44

hello 🙂 most people doing serious work with this are integrating Pathom with datomic in a more manual way (writing specific resolvers for parts of the attributes)

wilkerlucio11:02:30

I know @U06B8J0AJ and @U06KD64RX played with pathom-datomic, they may be able to give a better user experiencie, I created it most as an experiment, this is part of Pathom Dynamic resolvers, which is the next thing I'll be working in Pathom 3

prnc12:02:31

ok, will have to experiment then, which is good as well 🙂 thanks @U066U8JQJ, the progress on pathom3 looks amazing, looking forward to seeing what’s next 🙂

henrik09:03:20

We found pathom-datomic to be a really nice default to get up and running. We use that as a "baseline", in order to not write a resolver for every single attribute in the DB, and then switch to resolvers for things where we need to inject more intelligence.

henrik09:03:50

Though we're currently on Pathom 2.

prnc09:03:07

Hi! Thanks so much @U06B8J0AJ. This is what I was thinking, starting out with pathom-datomic. Pathom3 looks tempting thought, esp. for a new/early stage project. Those two are incompatible though right? (i.e. pathom-datomic & pathom3)

henrik10:03:23

I'm not sure @U7MHWDLD8, we haven't tried Pathom 3 yet. When you use Datomic, it's crucial that you can update the environment mid-mutation (since when you transact to Datomic, you need to get a new DB from the result, and inject it into the Pathom env in order for subsequent resolvers to use the correct DB for responses). I'm not sure if Pathom 3 has that yet (@U066U8JQJ did take notice of this in a previous thread), but if it doesn't, I'd recommend sticking to Pathom 2 for the time being.

prnc10:03:30

Alright! Will need to do some experimenting now I guess but this very helpful to get me started, thank you!

👍 3
wilkerlucio13:03:02

one thing to also consider is that Pathom 2 datomic support relies on reader3, which I suggest everyone to avoid, its a dropped experiment in Pathom 2, the Pathom 3 port for that should be easy enough, I'm currently working on dynamic resolvers support (starting with GraphQL because its a harder problem and will get more things clear)

henrik13:03:48

@U066U8JQJ Would you suggest that it's a better idea to go with Pathom 3 at this point, and just write the resolvers required, than to go with Pathom 2 + pathom-datomic + reader3?

wilkerlucio13:03:51

at this exact point you couldn't use the Pathom Datomic with Pathom 3, the safe way to go still Pathom 2 + reader2 + manual resolvers. reader3 has issues that were fixes in Pathom 3 already (bad planning in some situations) but not backported (because there is a lot of non Pathom 2 related things on the Pathom 3 impl). But I'm getting confident with the basics in Pathom 3, experiments have been running fine, and Datomic for Pathom 3 is right around the corner (I guess 1 week, 2 tops), Pathom 3 + Datomic dynamic will be probably safer than Pathom 2 + reader3

👍 3
prnc14:03:35

> Datomic for Pathom 3 is right around the corner (I guess 1 week, 2 tops) that’s some good news, very exciting!

magra10:02:02

Thank you für pathom!! I just upgraded from pathom 2.2.31 to 2.3.1. This causes a massive slowdown on my setup. I have a fulcro app that queries for massively nested trees on load and then works with small changes afterwards. I wrapped the parser with time , which reports "Elapsed time: 3122.194217 msecs" with 2.2.31 and "Elapsed time: 429305.222488 msecs" with 2.3.1. The fans start humming. Is this a known issue? Should I start to debug or should I wait for 3.x and stick to 2.231 in the meantime? I am using p/parser, pc/mutate, p/map-reader and pc/reader2.

wilkerlucio11:02:03

hello, are you using Guardrails in your project?

wilkerlucio11:02:00

last time I had a long talk with Tony, and we realised in the end the problem is that in this jump Pathom started using guardrails internally, and then when the user has Guardrails on it causes this kind of slowness in development

magra12:02:00

Switching off :com.wsscode.pathom/trace fixes it.

magra12:02:07

Yes, I am using Guradrails.

wilkerlucio12:02:06

so yeah, Pathom now also pays guardrails price, and that makes slow in dev, but prod still the same

wilkerlucio12:02:17

you can check on your side by turning guardrails off

magra13:02:54

yes, without guardrails timereturns "Elapsed time: 2452.635043 msecs"

magra13:02:59

Thank you!

magra13:02:39

For your fast reply and for your work on pathom!!

magra13:02:51

And I love your song 🙂

wilkerlucio13:02:52

hahah, thanks!

wilkerlucio14:02:19

hello people, a bit of early news, very excited to say that Pathom 3 is now runnable in Babashka scripts! I'm super happy about it, this means we can now use Pathom engine to make scripts that run blazing fast!

👏 48
wilkerlucio14:02:44

this needs to be merged before it fully works, but if you use git deps and point to my commit there it works https://github.com/fulcrologic/guardrails/pull/21

wilkerlucio14:02:25

Smart Maps currently don't work, given they require Potemkim, which uses a ton of weird features that Babashka doesn't support, I'm investigating if its possible to make a separate simpler implementation that works in Babashka

wilkerlucio14:02:06

(also requires the latest babashka snapshot, that you can download from #babashka-circleci-builds)

Jakub Holý (HolyJak)19:02:57

Interesting. Do you know of any use cases?

jeroenvandijk09:03:49

Interesting indeed. Do you have an example babashka script somewhere?