Fork me on GitHub
#pathom
<
2019-08-16
>
kenny00:08:13

Are there any examples of using pathom with Datomic? I'm curious about the various approaches you could take.

wilkerlucio03:08:39

hello Kenny, welcome, so far no docs yet, but I plan to add those since there is a lot of people that ask. I have never used pathom with datomic myself, but what most people are doing is writing one resolver for each "entity" that returns the scalar values of it, while relationships usually get their own resolver, that makes sense?

kenny14:08:55

Yep! Going for a POC within the next week. If each entity has their own resolver, is each resolver parameterized, somehow, to only pull the necessary attributes from Datomic?

wilkerlucio15:08:02

it could be done, but to be honest it seems like fetching those extra things on the pull is not a problem (specially if you are not running on datomic cloud). for the user output EQL will select only the request keys, so the extra on the pull will live only during processing time (so they can used to process other dependencies, but unless the user asks for then, they will not appear in the output)

kenny15:08:27

Yeah, generally seems pretty low cost. Maybe in the same realm, if you have several nested entities and a resolver per entity, won't that result in several Datomic pull's? It seems more efficient to just do the pull at the root.

wilkerlucio18:08:45

yeah, in the ideal world we could detect what can be resolved from the query and delegate as much as possible to pull and send that subquery there, and later process the rest. but since we don't have that integration (GraphQL integration does a similar thing, but there is nothing for Datomic at this time) its about trying out and balacing according to your use case. makes sense?

kenny18:08:32

Right, makes sense.

Vincent Cantin13:08:12

I have a question: how would you do to map resolvers to APIs which require multiple input parameters, with those parameter's numericity been one-to-many.. For example, imagine a legacy API designed like that: GET /api/{blogId}/{articleId}/{versionId}/md

kszabo13:08:53

for these kind of scenarios I just use the fact that you can use rich EDN for idents

kszabo13:08:31

i.e: {[:my-legacy-req-map {:blog-id 1 :article-id 2 :version-id 4}] [:foo :bar]}

kszabo13:08:35

essentially you create an entity with composite keys via maps

kszabo13:08:55

and the resolvers can map to your regular old :blog/id :article/id :version/id entities allowing graph traversal

Vincent Cantin13:08:21

I think that it would work, but I don't like seeing the bad design pattern of the API leaking into the queries. The user of pathom is supposed not to remember how the API is structured, ideally.

Vincent Cantin13:08:46

I would be happy if there was a solution involving only the resolvers.

kszabo13:08:06

If you have a datasource which requires 3 things to look up something, you can鈥檛 express it without any less. The only alternative I see is via using :pathom/context

Vincent Cantin13:08:06

or ... maybe the {:blog-id 1 :article-id 2 :version-id 4} data could be the output of a resolver ..

kszabo13:08:45

that way you could define a resolver which requires the ids of the 3 above and output whatever is under /md for that resource

Vincent Cantin13:08:04

like that :blog-id -> :blog-article-id -> :blog-article-version-id ?

kszabo13:08:35

[{([:github.repository/name "pathom"] {:pathom/context {:github.repository/owner "wilkerlucio"}}) [...]}]

kszabo13:08:40

this is essentially the same problem

馃憤 4
eoliphant13:08:42

the existing parameter support should work fine no? [(::blog {:id .. :article .. :version ..) ...])

eoliphant13:08:34

ah but I see the issue in terms of idents

Vincent Cantin13:08:14

I think my solution would work, but I did not test it yet. It would look like that .. Resolvers: - "get-blog-articles" [:blog-id] -> [:article-id :blog-article-id] - "get-article-versions" [:blog-article-id] -> [:version-id :blog-article-version-id] - "get-version-markdown" [:blog-article-version-id] -> [:markdown] A query could then be as simple as: [{:blog-id [{:article-id [{:version-id [:markdown]}]}]}

Vincent Cantin14:08:52

Do you think it would work?

Vincent Cantin14:08:29

The trick would be to have a 1-to-1 relation with some data and the path which was used to reach it, and let pathom use it when it is needed.

wilkerlucio14:08:58

@vincent.cantin if you dealing with an API that requires the whole path to reach some entity, I would consider that a composite key, so a composed ident can work, as: [:article/id ["blog-id" "article-id" "version"]], the solution you proposed can work, but adds "nesting requirements" and can make hard to point directly to the resource, if you use something like Fulcro it really helps if you have a global atomic identifier for everything so it can be used as reference for that resource. You can also get creative about how to generate this, you can have processes to figure out other parts (if makes sense and the API provides support, for example, you could have something without the article version that resolves the latest and fills up the version, returning the final article ident complete)

馃憤 4
Vincent Cantin14:08:59

Yes, that helps. You are right, the nesting requirement is not good.