Thanks! I think pathom caching can solve what I'm trying to accomplish. Will give that a go!
Hi all. Wondering if anyone is using Pathom to pull from an sql type db or does this really only make sense with datalog? Wondering if Pathom builds an optimized query of some sort or does it run the resolvers body as it builds the plan?
Hey @limix I mostly work on #datomic -like apps But I use #pathom as my default "data source" Any data that I need: an database access, an http requests, s3, etc... I access throught #pathom resolvers. So, if I worked with SQL, i would use pathom/resolvers to it too. #walkable tries to resolve a harder problem: expose an SQL DB as an graph API (via pathom). Even if you don't use #walkable, you can use #pathom , writing resolvers manually with your own queries.
TL;DR: you don't NEED #walkable to use #pathom with #sql, but when #walkable be ready, it will be an awesome lib.
@souenzzo thank you for the explanation. Just out of curiosity, are you ever building restful endpoints as well with Pathom or mostly eql or graphql endpoints?
It's easy to create #pedestal endpoints, for example, getting data from pathom.
You can use [(:my-ns/my-name {:pathom/as :name})]
to get the value as {:name "example"}
I do mostly like this:
https://github.com/souenzzo/eql-as#real-world-exmaple
There is also an internal tooling on company that checks if the query that we run on the endpoint "conforms" with the swagger/openapi spec.
Thank you @souenzzo looks great
Checkout #walkable
@souenzzo thank you, checking it now