pathom 2022-02-11 | Slack Archive

markaddleman14:02:28

I'm using Pathom on the server-side to help organize the code that generates large and somewhat complex SQL for an analytics application. I have resolvers that generate filter expressions, aggregations, joins etc. In many cases it takes several hundred milliseconds to generate the SQL. In the common case, the structure of the SQL remains the same only the particular values change - ie, this is a perfect case for prepared statements and query variables. What I think I want to do is, continue to use Pathom to generate the SQL but, rather than the input to resolvers being actual values, I want the input to be the path to the values. The application would generate a HoneySQL-like data structure but with paths for values. At the end of processing, I'd have a resolver replace the paths with actual values. This way, I can use Pathom's caching system to cache the HoneySQL data structure thus saving several hundred milliseconds (in most cases). My question is this: Does this make any sense? Is there a way for a resolver to get its inputs as paths rather than values?

sheluchin15:02:31

I'm curious about your implementation. Do you happen to have any of the source available?

wilkerlucio15:02:45

I feel like getting the paths is not really a thing here, because Pathom processes one entity at a time, and its about flowing values though the resolvers. for nested inputs it kind just goes and modifies the queries for deeper values, but its kind like they were flat for your description seems like you could try to do something by processing the plan instead of doing stuff at the run step dynamic resolvers also seem to fit here, in this case its about separating the parts of your query that are related to SQL vs parts that you will process with pathom resolvers, with dynamic resolvers you can leverage Pathom capabilities to isolate the SQL parts (by making them a single dynamic resolver), then in the dynamic resolver you gonna receive just the SQL query parts, and them you can process on top of it

markaddleman16:02:49

@UPWHQK562 Unfortunately, this is proprietary code and I can't share it directly but I'm happy to answer your questions. In fact, I have been meaning to write a blog article on how we're using Pathom so answering your questions would be helpful for me!

markaddleman16:02:25

@U066U8JQJ - Thanks for the pointer. Processing the plan does seem like a good idea. Can you point me to the API to obtain the plan without calling process ? Or, do you think I should invoke using process and use an interceptor to skip resolvers if appropriate? Your idea for dynamic resolvers also seems really interesting. I need to study up on dynamic resolvers to understand the details. I'm sure I'll have lots of questions as I move forward.

markaddleman16:02:27

Thanks!

myguidingstar07:02:01

@U2845S9KL that kind of prepared statements is actually what's already available with https://walkable.gitlab.io though I didn't have time to write the doc for that (and for many other things). Besides capturing values in closures, you can leverage walkable's ability to generate in advance as much as possible the sql string from data structure. For instance, if you have this data structure [:and [:< 1 'foo-var] [:< 'bar-var 10]], walkable can generate this string ((? < 1) AND (? < 10)) and you will only need to provide values for the vars (for instance {'foo-var 3, 'bar-var 7} in this case) to have it realized automatically to ((3 < 1) AND (7 < 10)).

markaddleman22:02:16

Thanks for the pointer to walkable! I looked at walkable several months ago and I did not think it suited my use case but now I understand my use case better and I can ask specific questions. I'll post to take this conversation over to #walkable

2022-02-11

Channels