-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we come up with a better term for @entityResolver
/ @finder
?
#15
Comments
The best things i could come up with were:
|
I think the first hurdle is to strictly define what an "Entity" is though right? Do we even need to do that? If we keep with existing spec terms, an "entity" is a GraphQL So would an even simpler term be something like:
Do we agree to use the term "entity" to indicate which types are annotated with the Some other ideas:
|
Some top contenders now, small and short preferred
|
I am closing this issue as the group has agreed to the term |
The draft specification in this repository proposes the directive
@entityResolver
as a marker for fields that allow looking up entities by their keys. At Apollo, we've had a longstanding proposal for similar functionality where we've used@finder
for the same functionality.We discussed the term entity resolvers internally, but decided it wasn't a good match because resolvers are part of the implementation of a schema, and what we're trying to convey here is the semantics of being able to look up an entity by its key (e.g. looking up a book by its
isbn
or a product by itsupc
). We've thought about@lookup
, but that didn't seem specific enough because you can look up entities by other characteristics as well (e.g. looking up all books written by a particular author).The text was updated successfully, but these errors were encountered: