5 ms·

> It's very cool you managed to make a mini Pathom - esp in so few lines of code :)) Thanks! The possibility of doing this had been on my mind for a while... a

> It's very cool you managed to make a mini Pathom - esp in so few lines of code :)) Thanks! The possibility of doing this had been on my mind for a while... and then I finally got around to trying it since all I had to do to get started was say "try making something like pathom but without [...]". I actually have all the prompts and feedback for the initial POC over here[1] since at the time I was using github issues/comments for my LLM-driven-development workflow. Over the past few weeks as prep for release I went over all the code manually (especially since the whole point of this thing is for the implementation to be easy to understand) and basically rewrote the whole thing, or at least that's what it felt like. > But the end result looks almost identical? Resolver declarations are a bit reorganized and look a bit cleaner - though you could do that with a wrapper around Pathom. Why not fork Pathom and just make some QOL adjustments? The main thing I was going for was just to reduce the implementation size; the tweaks I made to e.g. `defresolver` were really just a side thing. To give some more background on the motivations, an issue I've had sometimes with Pathom is figuring out what's going wrong when my queries don't give me the results I'd expect. A few times as part of that I've gone spelunking through the Pathom codebase but still had never built up a complete understanding of how the query planning and execution works, which has meant that my debugging has always been more trial-and-error / black-box than I'd prefer. So I wanted to see "what is the least complex way that I could take an EQL query and figure out the results, even if the way I do it is dumber than the way Pathom does it?" i.e. I'm trying to minimize the amount of time it takes for someone to read the code and understand exactly what's going on under the hood. Hence layering more code on top of Pathom would only hinder that goal. [1] https://github.com/jacobobryant/biff.graph/issues?q=is%3Aissue%20state%3Aclosed https://github.com/jacobobryant/biff.graph/issues?q=is%3Aiss...

geokon 3mo ago
> the tweaks I made to e.g. `defresolver` were really just a side thing If it weren't for those, would Pathom be a drop-in replacement? Or is there different logic? I'm a bit of a beginner with this all myself, so yeah, I get how it's a bit of a black box :)) Think it's very cool you re-implemented it. > To give some more background on the motivations, an issue I've had sometimes with Pathom is figuring out what's going wrong when my queries don't give me the results I'd expect I'm curious in what scenario PathomViz is not giving enough info. I had a lot of trouble getting it working tbh (never got the nested query working) but from the docs it seems like it should give you all the information you'd need to reason back to why you get a particular output. Reimplement all this debugging stuff seems potentially a lot of work - but maybe I'm wrong. More tools around the diagnostic output https://pathom3.wsscode.com/docs/debugging/ https://pathom3.wsscode.com/docs/debugging/ is something I hope to explore eventually.
- jacobobryant 3mo ago
  > If it weren't for those, would Pathom be a drop-in replacement? Or is there different logic? I could've written biff.graph to work with actual Pathom resolvers. In fact it wouldn't be hard to write a shim that takes Pathom resolvers and returns biff.graph resolvers. Although not all resolvers would work since biff.graph doesn't support everything in EQL (e.g. union queries, attribute parameters). The query results aren't strictly guaranteed to be the same, so even with a shim I wouldn't recommend dropping biff.graph into a large project that's already using Pathom. And then that's not even getting into all the Pathom features that biff.graph doesn't support at all (lenient mode, plugins, async mode, the graphql adapter...). But as for the core concepts, yeah I'd say they're pretty close. > I'm curious in what scenario PathomViz is not giving enough info. I had a lot of trouble getting it working tbh I had that trouble too heh heh--I tried running it I know at least once but didn't succeed. I don't remember exactly what the issue was... but I probably should figure that out. Even if I got better at debugging Pathom though, for Biff I would still prefer to have an implementation that's easier for users to understand so that ideally they don't even need extra tools to aid with debugging. FWIW there is an example here[1] of what the biff.graph error looks like when a nested required attribute can't be resolved. That file also has examples of some additional validation logic I've thrown in, e.g. biff.graph will complain if one resolver declares an attribute as a join and another resolver declares it as a scalar. Sometime for our codebase at work I'll probably write some assertions to do those kinds of checks on our Pathom resolvers. [1] https://github.com/jacobobryant/biff/blob/v2.x/libs/graph/docs/error-examples.md https://github.com/jacobobryant/biff/blob/v2.x/libs/graph/do...
  - geokon 3mo ago
    Oh sorry, I kind of meant it the other way around. You start with biff.graph and you'd swap in Pathom if the featureset or performance wasn't adequate. It makes sense that since you support a subset that it doesn't work the other way around! It might make sense to reinvent the wheel if there is a clear gain - but if there isn't any big innovation going on in the library interface, it's generally nice to keep the same interface if it's easy enough to do - but that's just my opinion haha And yeah, now that I have a larger application with Pathom.. I should retry Viz too :)) And that's very cool you're taking error seriously. Sorry, I missed it when I looked at the rep the first time! Thanks for your help with Pathom a few months back (kxygk on Github)

geokon 3mo ago

> the tweaks I made to e.g. `defresolver` were really just a side thing If it weren't for those, would Pathom be a drop-in replacement? Or is there different logic? I'm a bit of a beginner with this all myself, so yeah, I get how it's a bit of a black box :)) Think it's very cool you re-implemented it. > To give some more background on the motivations, an issue I've had sometimes with Pathom is figuring out what's going wrong when my queries don't give me the results I'd expect I'm curious in what scenario PathomViz is not giving enough info. I had a lot of trouble getting it working tbh (never got the nested query working) but from the docs it seems like it should give you all the information you'd need to reason back to why you get a particular output. Reimplement all this debugging stuff seems potentially a lot of work - but maybe I'm wrong. More tools around the diagnostic output https://pathom3.wsscode.com/docs/debugging/ https://pathom3.wsscode.com/docs/debugging/ is something I hope to explore eventually.

jacobobryant 3mo ago
> If it weren't for those, would Pathom be a drop-in replacement? Or is there different logic? I could've written biff.graph to work with actual Pathom resolvers. In fact it wouldn't be hard to write a shim that takes Pathom resolvers and returns biff.graph resolvers. Although not all resolvers would work since biff.graph doesn't support everything in EQL (e.g. union queries, attribute parameters). The query results aren't strictly guaranteed to be the same, so even with a shim I wouldn't recommend dropping biff.graph into a large project that's already using Pathom. And then that's not even getting into all the Pathom features that biff.graph doesn't support at all (lenient mode, plugins, async mode, the graphql adapter...). But as for the core concepts, yeah I'd say they're pretty close. > I'm curious in what scenario PathomViz is not giving enough info. I had a lot of trouble getting it working tbh I had that trouble too heh heh--I tried running it I know at least once but didn't succeed. I don't remember exactly what the issue was... but I probably should figure that out. Even if I got better at debugging Pathom though, for Biff I would still prefer to have an implementation that's easier for users to understand so that ideally they don't even need extra tools to aid with debugging. FWIW there is an example here[1] of what the biff.graph error looks like when a nested required attribute can't be resolved. That file also has examples of some additional validation logic I've thrown in, e.g. biff.graph will complain if one resolver declares an attribute as a join and another resolver declares it as a scalar. Sometime for our codebase at work I'll probably write some assertions to do those kinds of checks on our Pathom resolvers. [1] https://github.com/jacobobryant/biff/blob/v2.x/libs/graph/docs/error-examples.md https://github.com/jacobobryant/biff/blob/v2.x/libs/graph/do...
- geokon 3mo ago
  Oh sorry, I kind of meant it the other way around. You start with biff.graph and you'd swap in Pathom if the featureset or performance wasn't adequate. It makes sense that since you support a subset that it doesn't work the other way around! It might make sense to reinvent the wheel if there is a clear gain - but if there isn't any big innovation going on in the library interface, it's generally nice to keep the same interface if it's easy enough to do - but that's just my opinion haha And yeah, now that I have a larger application with Pathom.. I should retry Viz too :)) And that's very cool you're taking error seriously. Sorry, I missed it when I looked at the rep the first time! Thanks for your help with Pathom a few months back (kxygk on Github)