Can we come up with a better term for `@entityResolver` / `@finder`?

[martijnwalraven]

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 its upc). 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).

[PascalSenn]

The best things i could come up with were:

• @matcher / @match: As you match the keys to the entity
• @join: As you join by keys (Please dont hate me)
• @binder / @bind: As you bind a resolver for a certain set of keys.
• @fetcher: As you "fetch" by keys. This one is not so good as it implies "fetching" but i still want to list it for documentation reasons

[smyrick]

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 Type that can be identified and resolved by specific fields (aka the @key directive today)

So would an even simpler term be something like:

You can annotate your GraphQL types with the @key directive to specify which fields should be used to resolver this object, and annotate the appropriate Query field with @typeResolver to indicate which field can resolve the data at runtime

Do we agree to use the term "entity" to indicate which types are annotated with the @key so using that term in the directive lines up?

Some other ideas:

• @typeReference
• @typeFetcher
• @entityFetcher
• @keyResolver
• @keyResolver
• @entityQuery

[smyrick]

Some top contenders now, small and short preferred

• @lookup
• @finder
• @entity

[michaelstaib]

I am closing this issue as the group has agreed to the term lookup.

https://github.com/graphql/composite-schemas-spec/pull/30