Fork me on GitHub
#pathom
<
2019-02-02
>
hmaurer13:02:03

@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?

hmaurer13:02:31

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

hmaurer13:02:39

pulling data for the page

wilkerlucio13:02:03

yup, IMO you should avoid simple keywords entirely

wilkerlucio13:02:34

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

hmaurer13:02:49

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

wilkerlucio14:02:40

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

wilkerlucio14:02:31

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

hmaurer14:02:34

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

hmaurer14:02:09

that makes sense for inter-system communication

wilkerlucio14:02:09

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

😄 5
wilkerlucio14:02:59

@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

hmaurer14:02:28

@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. :my-app.my-module.some-entity/some-property and they got very long. Perhaps the app prefix is enough

hmaurer14:02:49

(I was doing this for specs)

wilkerlucio14:02:20

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

wilkerlucio14:02:36

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

wilkerlucio14:02:18

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)

pvillegas1214:02:58

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

pvillegas1214:02:20

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?

pvillegas1215:02:14

(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)

wilkerlucio15:02:18

@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

wilkerlucio15:02:52

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

pvillegas1215:02:32

why would they avoid exposing the whole tree?

wilkerlucio15:02:38

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

pvillegas1215:02:07

you mean when you introspect it?

wilkerlucio15:02:17

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

pvillegas1215:02:40

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

pvillegas1215:02:47

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 private.data/ namespace for example?

wilkerlucio15:02:18

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

pvillegas1215:02:37

yeah, this conversation is useful either way for me 😄

wilkerlucio15:02:39

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

wilkerlucio15:02:41

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

wilkerlucio15:02:56

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

wilkerlucio15:02:12

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

wilkerlucio15:02:41

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

pvillegas1215:02:37

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