Docs (GraphQL): 21.03 feature documentation for federation #104

vardhanapoorv · 2021-03-09T12:01:53Z

Docs regarding support for Apollo federation.
Fixes DOC-156

netlify · 2021-03-09T12:03:27Z

Deploy preview for dgraph-docs-repo ready!

Built with commit 12bc2f5

https://deploy-preview-104--dgraph-docs-repo.netlify.app

aaroncarey · 2021-03-09T17:34:17Z

content/graphql/federation/index.md

@@ -0,0 +1,129 @@
+++
+title = "Apollo Federation"
+weight = 14


Please add a "description" under "title" to give us a description for SEO. Suggestion:

description = "Dgraph now supports Apollo federation so that you can create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services."

Thanks for adding this!

aaroncarey

Great content! I added a few comments.

aaroncarey · 2021-03-09T17:47:53Z

content/graphql/federation/index.md

+  parent = "graphql"
+++
+
+Starting from release version 21.03 support has been added for Apollo federation. Hence making it possible to use Dgraph GraphQL API with other GraphQL services through a single gateway.


Suggested change

Starting from release version 21.03 support has been added for Apollo federation. Hence making it possible to use Dgraph GraphQL API with other GraphQL services through a single gateway.

Dgraph supports Apollo federation starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.

Edited to remove passive voice

aaroncarey · 2021-03-09T17:48:48Z

content/graphql/federation/index.md

+
+## Support for Apollo federation directives
+
+The current implementation supports 3 directives, namely `@key`, `@extends`, and `@external`.


Suggested change

The current implementation supports 3 directives, namely `@key`, `@extends`, and `@external`.

The current implementation supports the following three directives: `@key`, `@extends`, and `@external`.

aaroncarey · 2021-03-09T17:53:17Z

content/graphql/federation/index.md

+The current implementation supports 3 directives, namely `@key`, `@extends`, and `@external`.
+
+### `@key` directive
+This directive takes one field argument inside it which is called `@key` field. There are few limitations on how to use `@key` directives.


Suggested change

This directive takes one field argument inside it which is called `@key` field. There are few limitations on how to use `@key` directives.

This directive takes one field argument inside it: the `@key` field. There are few limitations on how to use `@key` directives:

aaroncarey · 2021-03-09T17:55:18Z

content/graphql/federation/index.md

+### `@key` directive
+This directive takes one field argument inside it which is called `@key` field. There are few 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.


The items on lines 19 and 20 should be three bullets, IMO (slight suggested rewording):

Users can define the @key directive only once for a type

Support for multiple key types is not currently available.

Since the @key field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the @key directive should be of ID type or have the @id directive on it.

Done, good point.

minhaj-shakeel · 2021-03-15T11:15:29Z

content/graphql/federation/index.md

+
+When adding an object of type `Astronaut`, first it should be added into `AstronautService` service and then the `addAstronaut` mutation should be called with value of `id` provided as an argument which must be equal to the value in `AstronautService` service.
+
+Remember to add the `Extended Definitions` block from the generated schema of Dgraph GraphQL to the other GraphQL services schemas that are part of the gateway. This needs to be done otherwise the Apollo gateway will throw an error like `Custom directives must be implemented in every service.`


We don't need to append Extended Definitions now. Please remove this block.

abhimanyusinghgaur · 2021-03-15T12:06:47Z

content/graphql/federation/index.md

+```
+
+### `@extends` directive
+This 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 directive.


Suggested change

This 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 directive.

This directive is provided to give support for extended definitions. Suppose the above defined `User` type is defined in some other service. Users can extend it in Dgraph's GraphQL service by using this directive.

We can also add that the same is also achievable with the extend keyword, i.e., user has the choice to choose between extend type User ... or type User @extends ...

abhimanyusinghgaur · 2021-03-15T12:07:09Z

content/graphql/federation/index.md

+This directive takes one field argument inside it: the `@key` field. There are few limitations on how to use `@key` directives:
+
+- Users can define the @key directive only once for a type
+- Support for multiple key types is not currently available.


Suggested change

- Support for multiple key types is not currently available.

- Support for multiple key fields is not currently available.

abhimanyusinghgaur · 2021-03-15T12:08:52Z

content/graphql/federation/index.md

+This 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 directive.
+```graphql
+type User @key(fields: "id") @extends{
+   id: ID! @external


Suggested change

id: ID! @external

id: String! @id @external

Let's use this, so that we have both the syntax for @key visible to users in docs.

abhimanyusinghgaur · 2021-03-15T12:10:40Z

content/graphql/federation/index.md

+  parent = "graphql"
+++
+
+Dgraph supports Apollo federation starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.


Suggested change

Dgraph supports Apollo federation starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.

Dgraph supports [Apollo federation](https://www.apollographql.com/docs/federation/) starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.

abhimanyusinghgaur · 2021-03-15T13:02:45Z

content/graphql/federation/index.md

+```
+
+When the gateway fetches `user.reviews` from the `review` service, the gateway will get `user.email` from the `User` service and provide it as an argument to the `_entities` query.
+


About @requires, we also need to add that:

If you feel the need to use `@requires`, you probably also want to add custom logic on such fields. You can do that using `@lambda`/`@custom(http: {...})`

See, this PR for example usage of @requires with @lambda and accordingly add an example here with @lambda: dgraph-io/dgraph#7558

abhimanyusinghgaur · 2021-03-15T13:09:37Z

content/graphql/federation/index.md

+```
+
+{{% notice "note" %}}
+Currently we only support federated queries, not federated mutations. We might support it in the future.


The apollo spec itself doesn't support federated mutations. So, I don't think we should even say that we might support them later.

abhimanyusinghgaur · 2021-03-15T13:12:31Z

content/graphql/federation/index.md

+Currently we only support federated queries, not federated mutations. We might support it in the future.
+{{% /notice %}}
+
+## Gateway supported directives


I feel this section is also irrelevant to users. They shouldn't be concerned about the bugs in the underlying libs. They only want to use the feature.
So, let's remove this section too.

abhimanyusinghgaur · 2021-03-15T13:12:42Z

content/graphql/federation/index.md

+
+When adding an object of type `Astronaut`, first it should be added into `AstronautService` service and then the `addAstronaut` mutation should be called with value of `id` provided as an argument which must be equal to the value in `AstronautService` service.
+
+Use the admin endpoint to query for the generated schema -


Let's remove the getGQLSchema thing from here, it is not relevant.

aaroncarey · 2021-03-16T23:05:57Z

content/graphql/federation/index.md

+### `@key` directive
+This directive takes one field argument inside it: the `@key` field. There are few limitations on how to use `@key` directives:
+
+- Users can define the @key directive only once for a type


Suggested change

- Users can define the @key directive only once for a type

- Users can define the `@key` directive only once for a type

aaroncarey · 2021-03-16T23:06:53Z

content/graphql/federation/index.md

+
+- Users can define the @key directive only once for a type
+- Support for multiple key fields is not currently available.
+- Since the @key field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the @key directive should be of ID type or have the @id directive on it.


Suggested change

- Since the @key field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the @key directive should be of ID type or have the @id directive on it.

- Since the `@key` field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the `@key` directive should be of `ID` type or have the `@id` directive on it.

aaroncarey · 2021-03-16T23:09:12Z

content/graphql/federation/index.md

+```
+
+### `@extends` directive
+This directive is provided to give support for extended definitions. Suppose the above defined `User` type is defined in some other service. Users can extend it in Dgraph's GraphQL service by using this directive. 


Suggested change

This directive is provided to give support for extended definitions. Suppose the above defined `User` type is defined in some other service. Users can extend it in Dgraph's GraphQL service by using this directive.

This directive provides support for extended definitions. For example, if the above-defined `User` type is defined in some other service, you can extend it in Dgraph's GraphQL service by using the `@extends` directive, as follows:

aaroncarey · 2021-03-16T23:10:44Z

content/graphql/federation/index.md

+  products: [Product]
+}
+```
+The same is also achievable with the `extend` keyword, i.e., user has the choice to choose between `extend type User ...` or `type User @extends ...`.


Suggested change

The same is also achievable with the `extend` keyword, i.e., user has the choice to choose between `extend type User ...` or `type User @extends ...`.

You can also achieve this with the `extend` keyword; so you have a choice between two types of syntax to extend a type into your Dgraph GraphQL service: `extend type User ...` or `type User @extends ...`.

aaroncarey · 2021-03-16T23:11:48Z

content/graphql/federation/index.md

+The same is also achievable with the `extend` keyword, i.e., user has the choice to choose between `extend type User ...` or `type User @extends ...`.
+
+### `@external` directive
+This directive is used when the given field is not stored in this service. It can only be used on extended type definitions. As it is used above on the `id` field of `User` type.


Suggested change

This directive is used when the given field is not stored in this service. It can only be used on extended type definitions. As it is used above on the `id` field of `User` type.

You use this directive when the given field is not stored in this service. It can only be used on extended type definitions. For example, it is used in the example shown above on the `id` field of the `User` type.

aaroncarey · 2021-03-16T23:13:58Z

content/graphql/federation/index.md

+This directive is used when the given field is not stored in this service. It can only be used on extended type definitions. As it is used above on the `id` field of `User` type.
+
+### `@provides` directive
+This directive is used on a field that tells the gateway to return a specific fieldSet from the base type while fetching the field. 


Suggested change

This directive is used on a field that tells the gateway to return a specific fieldSet from the base type while fetching the field.

You use this directive on a field that tells the gateway to return a specific fieldset from the base type while fetching the field.

Per https://www.apollographql.com/docs/federation/federation-spec/#scalar-_fieldset, we should either write "fieldset" or _FieldSet. The first one makes more sense to me in this context, but I could be wrong.

aaroncarey · 2021-03-16T23:17:09Z

content/graphql/federation/index.md

+}
+```
+
+While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself, meaning that it also resolves these fields, even though both fields are `@external`.


Suggested change

While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself, meaning that it also resolves these fields, even though both fields are `@external`.

While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself. So, the `review` service also resolves these fields, even though both fields are `@external`.

Breaking this into two sentences makes it easier to parse (and machine-translate)

aaroncarey · 2021-03-16T23:19:15Z

content/graphql/federation/index.md

+While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself, meaning that it also resolves these fields, even though both fields are `@external`.
+
+### `@requires` directive
+This directive is used on a field to annotate the fieldSet of the base type. It is used to develop a query plan where the required fields may not be needed by the client, but the service may need additional information from other services. 


Suggested change

This directive is used on a field to annotate the fieldSet of the base type. It is used to develop a query plan where the required fields may not be needed by the client, but the service may need additional information from other services.

You use this directive on a field to annotate the fieldset of the base type. You can use it to develop a query plan where the required fields may not be needed by the client, but the service may need additional information from other services.

aaroncarey · 2021-03-16T23:21:16Z

content/graphql/federation/index.md

+
+When the gateway fetches `user.reviews` from the `review` service, the gateway will get `user.email` from the `User` service and provide it as an argument to the `_entities` query.
+
+Using `@requires` alone on a field doesn't make much sense. In cases, where you feel the need to use `@requires`, you would want some custom logic on that field too. You can achieve that using `@lambda` or `@custom(http: {...})` directives.


Suggested change

Using `@requires` alone on a field doesn't make much sense. In cases, where you feel the need to use `@requires`, you would want some custom logic on that field too. You can achieve that using `@lambda` or `@custom(http: {...})` directives.

Using `@requires` alone on a field doesn't make much sense. In cases where you need to use `@requires`, you should also add some custom logic on that field. You can add such logic using the `@lambda` or `@custom(http: {...})` directives.

aaroncarey · 2021-03-16T23:22:54Z

content/graphql/federation/index.md

+}
+```
+
+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 API endpoint.


Suggested change

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 API endpoint.

The queries for `Astronaut` are not exposed to the gateway because they are resolved through the `_entities` resolver. However, these queries are available on the Dgraph GraphQL API endpoint.

aaroncarey · 2021-03-16T23:23:29Z

content/graphql/federation/index.md

+
+## Mutation for `extended` types
+If you want to add an object of `Astronaut` type which is extended in this service.
+The mutation `addAstronaut` takes `AddAstronautInput` which is generated as -


Suggested change

The mutation `addAstronaut` takes `AddAstronautInput` which is generated as -

The mutation `addAstronaut` takes `AddAstronautInput`, which is generated as follows:

aaroncarey · 2021-03-16T23:25:31Z

content/graphql/federation/index.md

+}
+```
+
+Even though the `id` field is of `ID` type which should be ideally generated internally by Dgraph. In this case, it should be provided as input since currently federated mutations aren't supported. The user should provide the value of `id` same as the value present in the GraphQL service where the type  `Astronaut` is defined.


Suggested change

Even though the `id` field is of `ID` type which should be ideally generated internally by Dgraph. In this case, it should be provided as input since currently federated mutations aren't supported. The user should provide the value of `id` same as the value present in the GraphQL service where the type `Astronaut` is defined.

The `id` field is of `ID` type, which is usually generated internally by Dgraph. In this case, it's provided as an input because federated mutations aren't currently supported. The user should provide the same `id` value that is present in the GraphQL service where the type `Astronaut` is defined.

aaroncarey · 2021-03-16T23:26:12Z

content/graphql/federation/index.md

+
+Even though the `id` field is of `ID` type which should be ideally generated internally by Dgraph. In this case, it should be provided as input since currently federated mutations aren't supported. 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 -


Suggested change

For example, let's take that the type `Astronaut` is defined in some other service `AstronautService` as -

For example, let's assume that the type `Astronaut` is defined in some other service, `AstronautService`, as follows:

aaroncarey · 2021-03-16T23:27:41Z

content/graphql/federation/index.md

+}
+```
+
+When adding an object of type `Astronaut`, first it should be added into `AstronautService` service and then the `addAstronaut` mutation should be called with value of `id` provided as an argument which must be equal to the value in `AstronautService` service.


Suggested change

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

When adding an object of type `Astronaut`, you should first add it to the `AstronautService` service. Then, you can call the `addAstronaut` mutation with the value of `id` provided as an argument that must be equal to the value in `AstronautService` service.

aaroncarey · 2021-03-16T23:32:21Z

Approved with suggested edits. You might want to add a "Known Issues" section at the bottom that will make it easy to see the limitation around mutations at-a-glance (especially if there are any other limitations that we want to highlight).

vardhanapoorv · 2021-03-17T08:15:54Z

@aaroncarey Abhimanyu mentioned that those things aren't supported by Apollo federation itself and hence it isn't a limitation, we shouldn't be mentioning it.

Add federation docs

2487e60

vardhanapoorv requested review from aaroncarey, bucanero and danielmai as code owners March 9, 2021 12:01

aaroncarey reviewed Mar 9, 2021

View reviewed changes

bucanero added this to the v21.03 milestone Mar 9, 2021

vardhanapoorv added 2 commits March 10, 2021 11:44

Address Aaron comments

efe7e90

Add two new directives

e6b8314

minhaj-shakeel reviewed Mar 15, 2021

View reviewed changes

Remove extended definitions block

defa5c4

abhimanyusinghgaur suggested changes Mar 15, 2021

View reviewed changes

Address Abhimanyu comments

3c382eb

abhimanyusinghgaur approved these changes Mar 16, 2021

View reviewed changes

aaroncarey reviewed Mar 16, 2021

View reviewed changes

Address Aaron comments

12bc2f5

aaroncarey merged commit 59a4a81 into master Mar 18, 2021

aaroncarey deleted the apoorv/federation branch March 18, 2021 15:41

	Starting from release version 21.03 support has been added for Apollo federation. Hence making it possible to use Dgraph GraphQL API with other GraphQL services through a single gateway.
	Dgraph supports Apollo federation starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.


		## Support for Apollo federation directives

		The current implementation supports 3 directives, namely `@key`, `@extends`, and `@external`.

	The current implementation supports 3 directives, namely `@key`, `@extends`, and `@external`.
	The current implementation supports the following three directives: `@key`, `@extends`, and `@external`.

	This directive takes one field argument inside it which is called `@key` field. There are few limitations on how to use `@key` directives.
	This directive takes one field argument inside it: the `@key` field. There are few limitations on how to use `@key` directives:


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

		Remember to add the `Extended Definitions` block from the generated schema of Dgraph GraphQL to the other GraphQL services schemas that are part of the gateway. This needs to be done otherwise the Apollo gateway will throw an error like `Custom directives must be implemented in every service.`

	This 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 directive.
	This directive is provided to give support for extended definitions. Suppose the above defined `User` type is defined in some other service. Users can extend it in Dgraph's GraphQL service by using this directive.

	- Support for multiple key types is not currently available.
	- Support for multiple key fields is not currently available.

	Dgraph supports Apollo federation starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.
	Dgraph supports [Apollo federation](https://www.apollographql.com/docs/federation/) starting in release version 21.03. This lets you create a gateway GraphQL service that includes the Dgraph GraphQL API and other GraphQL services.

		```

		When the gateway fetches `user.reviews` from the `review` service, the gateway will get `user.email` from the `User` service and provide it as an argument to the `_entities` query.


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

		Use the admin endpoint to query for the generated schema -

	- Users can define the @key directive only once for a type
	- Users can define the `@key` directive only once for a type

	- Since the @key field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the @key directive should be of ID type or have the @id directive on it.
	- Since the `@key` field acts as a foreign key to resolve entities from the service where it is extended, the field provided as an argument inside the `@key` directive should be of `ID` type or have the `@id` directive on it.

	This directive is provided to give support for extended definitions. Suppose the above defined `User` type is defined in some other service. Users can extend it in Dgraph's GraphQL service by using this directive.
	This directive provides support for extended definitions. For example, if the above-defined `User` type is defined in some other service, you can extend it in Dgraph's GraphQL service by using the `@extends` directive, as follows:

	The same is also achievable with the `extend` keyword, i.e., user has the choice to choose between `extend type User ...` or `type User @extends ...`.
	You can also achieve this with the `extend` keyword; so you have a choice between two types of syntax to extend a type into your Dgraph GraphQL service: `extend type User ...` or `type User @extends ...`.

	This directive is used when the given field is not stored in this service. It can only be used on extended type definitions. As it is used above on the `id` field of `User` type.
	You use this directive when the given field is not stored in this service. It can only be used on extended type definitions. For example, it is used in the example shown above on the `id` field of the `User` type.

	This directive is used on a field that tells the gateway to return a specific fieldSet from the base type while fetching the field.
	You use this directive on a field that tells the gateway to return a specific fieldset from the base type while fetching the field.

	While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself, meaning that it also resolves these fields, even though both fields are `@external`.
	While fetching `Review.product` from the `review` service, and if the `name` or `price` is also queried, the gateway will fetch these from the `review` service itself. So, the `review` service also resolves these fields, even though both fields are `@external`.

	This directive is used on a field to annotate the fieldSet of the base type. It is used to develop a query plan where the required fields may not be needed by the client, but the service may need additional information from other services.
	You use this directive on a field to annotate the fieldset of the base type. You can use it to develop a query plan where the required fields may not be needed by the client, but the service may need additional information from other services.


		When the gateway fetches `user.reviews` from the `review` service, the gateway will get `user.email` from the `User` service and provide it as an argument to the `_entities` query.

		Using `@requires` alone on a field doesn't make much sense. In cases, where you feel the need to use `@requires`, you would want some custom logic on that field too. You can achieve that using `@lambda` or `@custom(http: {...})` directives.

	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 API endpoint.
	The queries for `Astronaut` are not exposed to the gateway because they are resolved through the `_entities` resolver. However, these queries are available on the Dgraph GraphQL API endpoint.

Docs (GraphQL): 21.03 feature documentation for federation #104

Docs (GraphQL): 21.03 feature documentation for federation #104

Conversation

vardhanapoorv commented Mar 9, 2021

netlify bot commented Mar 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaroncarey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abhimanyusinghgaur Mar 15, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaroncarey Mar 16, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaroncarey commented Mar 16, 2021

vardhanapoorv commented Mar 17, 2021

netlify bot commented Mar 9, 2021 •

edited

Loading

abhimanyusinghgaur Mar 15, 2021 •

edited

Loading

aaroncarey Mar 16, 2021 •

edited

Loading

	The mutation `addAstronaut` takes `AddAstronautInput` which is generated as -
	The mutation `addAstronaut` takes `AddAstronautInput`, which is generated as follows:

	Even though the `id` field is of `ID` type which should be ideally generated internally by Dgraph. In this case, it should be provided as input since currently federated mutations aren't supported. The user should provide the value of `id` same as the value present in the GraphQL service where the type `Astronaut` is defined.
	The `id` field is of `ID` type, which is usually generated internally by Dgraph. In this case, it's provided as an input because federated mutations aren't currently supported. The user should provide the same `id` value that is present in the GraphQL service where the type `Astronaut` is defined.


		Even though the `id` field is of `ID` type which should be ideally generated internally by Dgraph. In this case, it should be provided as input since currently federated mutations aren't supported. 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 -

	For example, let's take that the type `Astronaut` is defined in some other service `AstronautService` as -
	For example, let's assume that the type `Astronaut` is defined in some other service, `AstronautService`, as follows: