Fork me on GitHub

@wilkerlucio more of a Pathom question so I’ll post it here: in my application I’ve found myself using :current-user as a root for pretty much everything, since all my data is user-dependent. Is that sensible?


So I have html5 routing set up, and on route change I load some query rooted at :current-user


pulling data for the page


yup, IMO you should avoid simple keywords entirely


because at some point systems will connect, if they both use simple keywords they can't talk without ambiguity


what do you mean? I should use :my-app/current-user?


thats a good topic for a documentation section, but yes, you app/company should prefix everything with its name


so would be :my-app/current-user :my-app.user/name ...


so even entities, instead of :user/first-name have :my-app.user/first-name.


that makes sense for inter-system communication


simple keywords are only good enough on demos, which is a problem because people copy from demos, heh

😄 5

@hmaurer also having qualified keywords allow you to get more data around it, because they are context free information, spec been the major example case for extracting more info about the keywords thenselves


@wilkerlucio yeah that makes perfect sense, although in my current project at some point I over-qualified keywords I think. I started qualifying them by module as well, e.g. and they got very long. Perhaps the app prefix is enough


(I was doing this for specs)


yeah, remembering that what matters is the name, the namespace is just a qualifier for the name to avoid collision


some people can argue using domain names (like Java does) but in practice I see project name been enough


for example, if we make a bunch of resolvers for youtube, that will hardly crash with anything else (unless someone is doing on purpose, not accidental)


Switching over here, as this is more pathom specific. For pathom, I see the most usefulness to manage multiple sources of data that do not implement a graphQL-like attribute level of querying. With Datomic, as we have pull syntax, we can pass most of Fulcro queries directly to a single resolver that hands of the query to d/pull


My question is: Given Datomic has pull, what is a good way to combine resolvers given we already have arbitrary query expressions in the db?


(I know in that expressing my API with pathom is the way to go, as I can later expose a graphQL API to talk to my data)


@pvillegas12 I'm afraid I can't help much with that because I lack experience using datomic with pathom, for what I see people tend to avoid exposing they whole datomic tree via pull, if you have that concern in mind then breaking it down and controlling whats acessible ends up been an asset, but if you are in a situation where uncontrolled access is ok (maybe something internal dev tool) then I think will be easier to use datomic entities instead of pull, maybe you will need a custom reader, but from that you could expose everything and combine with resolvers for computed values


about the graphql out, that's something I want to do, but its not there yet, pathom can consume graphql apis, but not expose it


why would they avoid exposing the whole tree?


because the UI has direct access to it, so it could leak private data, since all connections would be exposed


you mean when you introspect it?


or just protected data in general, delegating all to datomic pull gives you no control, so you dont want your end user to have direct access to it


I was thinking more of datomic pull + policy logic in the resolver env


Let’s see if I understand this, you’re saying create a resolver that does a d/pull and then do a select-keys without the namespace for example?


correct, that's the point, you have to be in the middle, you cant blindly send it over, but I'm just speculating possibilities that you could try, as I told I have no experience using datomic with pathom


yeah, this conversation is useful either way for me 😄


yes, but think about nested queries, then can get complicated to "select-keys"


so what I see people doing is providing level 0 and level 1 nesting on their pull patterns


like: [:user/name {:user/addresses [:address/id]}]


so no more than 1 nesting level, and leave the "ids" in place so other resolvers will pick up an continue


with this pattern each resolver level have control over "one resource" kind, and you can split more depending on how much control you want to have


Got it, so the resolver specifies which keys you want to expose publicly essentially