Juniper: Federation specification implementation

[snnsnn]

I don't know if it is too early to implement federation specification in juniper but please can you add it to your road map. Basically it is a way to composable GraphQL schemas using primitives (provided by @apollo/federation package) that replaces schema stitching.

• https://www.apollographql.com/docs/apollo-server/federation/introduction/
• https://www.apollographql.com/docs/apollo-server/federation/federation-spec/
• https://github.com/apollographql/apollo-server/tree/master/packages/apollo-federation
• https://github.com/apollographql/apollo-server/tree/master/packages/apollo-gateway

[LegNeato]

I don't think we would ever implement this as it is non-standard. Potentially we would take a PR with a an optional feature though!

[snnsnn]

Please can you consider implementing just the additions:

Federated services will need to implement the following additions to the schema to allow the gateway to use the service for execution:

scalar _Any
scalar _FieldSet

# a union of all types that use the @key directive
union _Entity

type _Service {
  sdl: String
}

extend type Query {
  _entities(representations: [_Any!]!): [_Entity]!
  _service: _Service!
}

directive @external on FIELD_DEFINITION
directive @requires(fields: _FieldSet!) on FIELD_DEFINITION
directive @provides(fields: _FieldSet!) on FIELD_DEFINITION
directive @key(fields: _FieldSet!) on OBJECT | INTERFACE

# this is an optional directive discussed below
directive @extends on OBJECT | INTERFACE

https://www.apollographql.com/docs/graphql-tools/schema-directives/

I think these additions will be enough to build federated graphql microservices.

With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.

Federation is fully declarative and doesn't require any user code to be running in the gateway.

Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.

I would be happy to send a PR but I don't trust my Rust skills yet.

[timtonk]

Well, it's not quite true. These additions are required, but not sufficient. We still need a way to define these external keys for fields for every gql object.
Given it's not in the spec, I agree with the opinion that it must be behind the feature flag. I rather wonder would we need to wait until #138 is done.

[japrogramer]

I think that having a way to declare custom directives should be added to juniper, as it is part of the spec https://spec.graphql.org/June2018/#sec-The-__Directive-Type