feat(GraphQL): Extend Support For Apollo Federation

[minhaj-shakeel]

Fixes GRAPHQL-917.

This PR extends support for the Apollo Federation.

Support for Apollo federation directives

Our current implementation allows support for 3 directives, namely @key, @extends and @external.

@key directive.

This directive is used on any type and it takes one field argument inside it which is called @key field. There are some limitations on how to use @key directives.

• User can define @key directive only once for a type, Support for multiple key types is not provided yet.
• Since the @key field act as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside @key directive should be of ID type or having @id directive on it. For example:-

type User @key(fields: "id") {
   id: ID!
  name: String
}

@extends directive.

@extends directive is provided to give support for extended definitions. Suppose the above defined User type is defined in some service. Users can extend it to our GraphQL service by using this keyword.

type User @key(fields: "id") @extends{
   id: ID! @external
  products: [Product]
}

@external directive.

@external directive means that the given field is not stored on this service. It is stored in some other service. This keyword can only be used on extended type definitions. Like it is used above on the id field.

Generated Queries and mutations

In this section, we will mention what all the queries and mutations will be available to individual service and to the apollo gateway. We will take the given schema as our example:-

type Mission @key(fields: "id") {
    id: ID!
    crew: [Astronaut]
    designation: String!
    startDate: String
    endDate: String
}

type Astronaut @key(fields: "id") @extends {
    id: ID! @external
    missions: [Mission]
}

The queries and mutations which are exposed to the gateway are:-

type Query {
	getMission(id: ID!): Mission
	queryMission(filter: MissionFilter, order: MissionOrder, first: Int, offset: Int): [Mission]
	aggregateMission(filter: MissionFilter): MissionAggregateResult
}

type Mutation {
	addMission(input: [AddMissionInput!]!): AddMissionPayload
	updateMission(input: UpdateMissionInput!): UpdateMissionPayload
	deleteMission(filter: MissionFilter!): DeleteMissionPayload
	addAstronaut(input: [AddAstronautInput!]!): AddAstronautPayload
	updateAstronaut(input: UpdateAstronautInput!): UpdateAstronautPayload
	deleteAstronaut(filter: AstronautFilter!): DeleteAstronautPayload
}

The queries for Astronaut are not exposed to the gateway since it will be resolved through the _entities resolver. Although these queries will be available on the Dgraph GraphQL endpoint.

Mutation for extended types

if we want to add an object of Astronaut type which is @Extended in this service.
The mutation addAstronaut takes AddAstronautInput which is generated as:-

input AddAstronautInput {
	id: ID!
	missions: [MissionRef]
}

Even though the id field is of ID type which should be ideally be generated internally by Dgraph, In this case, it should be provided as input. The reason for this is because of the unavailability of federated mutations, the user should provide the value of id same as the value present in the GraphQL service where the type Astronaut is defined.
For example, let's take that the type Astronaut is defined in some other service AstronautService as:-

type Astronaut @key(fields: "id") {
    id: ID! 
    name: String!
}

When adding an Object of Astronaut type, first it should be added into AstronautService and then the addAstronaut mutation should be called and value of id provided as an argument must be equal to the value in AstronautService.

Gateway Supported Directives.

Due to the bug in the federation library (see here), some directives are removed from the schema SDL which is returned to the gateway in response to the _service query.
Those directives are @custom, @generate, and @auth.
You can still use these directives in your GraphQL schema and they will work as desired but the gateway will unaware of this.

---

This change is 

[netlify]

Deploy preview for dgraph-docs ready!

Built with commit 359bac4

https://deploy-preview-7275--dgraph-docs.netlify.app

[pawanrawal]

Reviewed 19 of 36 files at r1, 11 of 14 files at r2, 2 of 2 files at r3, 8 of 8 files at r4.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @minhaj-shakeel)

---

graphql/admin/admin.go, line 860 at r4 (raw file):

					defer as.mux.RUnlock()
					sch := as.schema.Schema
					handler, _ := schema.NewHandler(sch, false, true)

Is the second argument error, what if there is an error?

---

graphql/dgraph/graphquery.go, line 153 at r4 (raw file):

		x.Check2(b.WriteString(fmt.Sprintf("(func: type(%s)", q.Func.Args[0].Value)))
	case q.Func.Name == "eq":
		x.Check2(b.WriteString("(func: eq("))

Can you add a comment here saying that for resolving _entities query, multiple arguments for eq would be required?

[minhaj-shakeel]

Reviewable status: 38 of 40 files reviewed, 2 unresolved discussions (waiting on @pawanrawal)

---

graphql/admin/admin.go, line 860 at r4 (raw file):

Previously, pawanrawal (Pawan Rawal) wrote…

Is the second argument error, what if there is an error?

Handled error properly.

---

graphql/dgraph/graphquery.go, line 153 at r4 (raw file):

Previously, pawanrawal (Pawan Rawal) wrote…

Can you add a comment here saying that for resolving _entities query, multiple arguments for eq would be required?

Done.