pathom

:pathom: https://github.com/wilkerlucio/pathom/ & https://pathom3.wsscode.com & https://roamresearch.com/#/app/wsscode
wilkerlucio 2021-02-04T01:40:48.166700Z

that can kill efficiency in a sense, ideally you can just write more resolvers and always be as specific as possible about your requirements, this is the way to maximize the utility of how pathom can optimize your code paths to fulfill data needs

wilkerlucio 2021-02-04T01:41:22.167Z

because if you give them as smart maps, you delay the point in which you know what you need

wilkerlucio 2021-02-04T01:41:36.167200Z

so each time you read, pathom has to go over the planning and running process again

wilkerlucio 2021-02-04T01:42:12.167400Z

while if you do in a single go, pathom can plan once, and with more information makes it more efficient (because it can optimize repeated paths and stuff like that)

markaddleman 2021-02-04T01:42:15.167600Z

"each time you read" - This means get operations on the smart map?

wilkerlucio 2021-02-04T01:42:19.167800Z

yeah

wilkerlucio 2021-02-04T01:42:52.168Z

doing a single query is much likely going to be faster than lazy loading one attribute at a time

wilkerlucio 2021-02-04T01:43:36.168300Z

I had that situation with Pathom Viz, I was using smart maps to compute trace data

markaddleman 2021-02-04T01:44:21.168500Z

Fair enough. Although, in my case, I think the only performance difference is Pathom's overhead to compute the plan. No matter what, I'm going to have to compute the result I care about. The only issue is whether the computation occurs as part of a smart-map get or as a direct function call

wilkerlucio 2021-02-04T01:44:26.168700Z

I was feeling some perf hit, and switch over to a pre-defined query in EQL, that got around 8x faster (because there was a lot of collection items, in those cases the usage of smart maps to do one attr a time adds up)

wilkerlucio 2021-02-04T01:45:09.168900Z

what I'm telling you is mostly about my perf expectations, but I like to encourage you to play around with a mixed approach, and Pathom totally supports that

wilkerlucio 2021-02-04T01:45:29.169100Z

you can write a plugin to make this happen

markaddleman 2021-02-04T01:45:54.169300Z

Oh, that's a good idea. I had planned on each resolver wrapping input in a smart map but a plugin is much more convenient

wilkerlucio 2021-02-04T01:45:54.169500Z

using the wrap-resolve hook, there, you can wrap the resolver call by transforming the input in a smart map, them you get what you asked for

markaddleman 2021-02-04T01:46:00.169700Z

Perfect

markaddleman 2021-02-04T01:46:53.169900Z

This whole conversation brings to mind something I've been wondering about: Given smart-maps, what is the right balance between function calls on maps vs get operations & resolvers

wilkerlucio 2021-02-04T01:46:58.170100Z

and I'm curious how this goes, would to learn more about what happens after some time doing that 🙂

wilkerlucio 2021-02-04T01:47:21.170300Z

function calls on maps?

markaddleman 2021-02-04T01:47:35.170500Z

I mean a function that takes a map as input

wilkerlucio 2021-02-04T01:51:09.170700Z

that's the design part, depends how much you want to delegate to pathom

wilkerlucio 2021-02-04T01:51:19.170900Z

or what "entry points" you wanna give to the system

wilkerlucio 2021-02-04T01:51:38.171100Z

I think a very open question, varies a lot

đź’Ż 1
tony.kay 2021-02-04T20:53:33.172700Z

How to I get to the reader “input”s in a Pathom 2 wrap read plugin? All I see is env, and I’m not sure where the inputs would be

tony.kay 2021-02-04T20:54:28.173100Z

do I have to do my own “select-keys” on the entity atom for the reader?

wilkerlucio 2021-02-04T21:10:53.173400Z

@tony.kay you can't on wrap-read, but you can on ::pc/wrap-resolve

tony.kay 2021-02-04T21:11:13.173700Z

AH

tony.kay 2021-02-04T21:11:16.173900Z

wrap-resolve!

tony.kay 2021-02-04T21:11:20.174100Z

wrong wrapper!

wilkerlucio 2021-02-04T21:11:44.174600Z

yup, the wrap-read will wrap the call to the reader chain

tony.kay 2021-02-04T21:12:27.175300Z

wow, went too low-level and totally got stuck…so easy