Add @key as primary key fields instead of nodeId

[jgzuke]

When using Graphile federated with another service, it seems to make more sense for the key to be on the primary keys of the resource instead of the nodeId. This is because any other resource would be likely to have access to the resource by its primary keys.

This can be worked around by adding @requires(fields: {primary keys}) to each other field and fetching by the keys in __resolveReference but this seemed like a bad solution.

[benjie]

This plugin is datasource-independent currently, there’s nothing PostgreSQL specific in it. This means it works with any Graphile Schema, not just PostGraphile, which is pretty cool I think.

That said, I’d like to allow other ways of specifying @key on various things, and your request is reasonable. Would be cool to add different federation strategies.

[benjie]

Sorry @key; I’ll try and remember to use backticks in future!

[jgzuke]

Hmm, im not sure what you mean by being able to work with any Graphile schema. If we used primaryKeyConstraint fields (if there are any), that seems like it would still work with any schema. I think im missing some detail.

[jgzuke]

I made #2 as an example of what ive been using locally in case my description before was unclear or not specific enough.

[benjie]

Graphile Engine is data-source independent. You can make GraphQL schemas with Graphile Engine that have nothing to do with PostgreSQL. PostGraphile then adds a bunch of plugins (graphile-build-pg) to build an automatic GraphQL API over PostgreSQL.

I’ll take a look at your PR 👍