Clojurians Log v2
pathom
If i'm wrapping API endpoints, is it more common or better to fully qualify all the keys deeply, or is it better to wrap the return in a fully qualified map for custom resolvers? i.e. is it better that my resolver return
::pco/output [{:fq/users [:id {:profile [:username :displayName}]}]
::pco/output [:fq/users]::pco/output [{:fq/users [:fq.user/id {:fq.user/profile [:fq.user.profile/username :fq.user.profile/displayName}]}][
{
"id": 1,
"profile":
{
"username": "user.01",
"displayName": "John Doe"
}
},
{
"id": 2,
"profile":
{
"username": "user.02",
"displayName": "Jane Doe"
}
},
{
"id": 3,
"profile":
{
"username": "user.03",
"displayName": "Jim Bo"
}
}
] If i can add to the question, is the recommendation to fully qualify the keys in a nesting and concatenating manner or is like the examples from the docs just fine for most apps?
[:fq.user/id {:fq.user/profile [:fq.user.profile/displayName]}]
or
[:fq/id {:fq/profile [:fq/displayName]}]
the former is preferred (with the entity type in the ns). one way to think about it: as your system grows, you gonna want to reference those attributes for extension, a good name is one that can represent a semantic idea without conflicting with other names in your system
maybe :fq.user.profile/displayName isn't necessary, does the profile really needs to be mapped as some other entity? other options would be:
:fq.user/display-name - just keep using the user
:fq.profile/display-name - use profile, but no need to make it a sub-thing of the user. Unless you have multiple types of profiles in the system, in that case you may want to keep using :fq.user.profile
makes sense?
It comes to personal preference however I would prefer to fully qualify everything. This would allow other resolvers/mutations that interact and use those same concepts to utilize the same fully qualified keyword so it's clear to the consumer which type of username, display name, etc. you're dealing with
yes, using qualified names are preferred, so you can distinctively reference them later
okay, i had a feeling that was the case. i guess more detail more better for the planner. that makes sense
ty both
oh okay yeah that makes sense! that clears up the right amount of detail that I should be shooting for. I was thinking maybe i was going too far with the nested data because I was getting some rather large pco/output values with some of these APIs and I was thinking maybe it was unnecessary, but I see where the detail can help as the system grows larger