fix(@nestjs/graphql) fix federated schema generated with code first approach

[keadex]

Federated schema generated with the code first approach does not contain
the directives.

Closes #1597

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #1597

What is the new behavior?

The generated schema contains also the directives needed for the federation.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

[kamilmysliwiec]

@apollo/federation is an optional dependency so we'd have to make it required

[keadex]

The GraphQLModule is a wrapper around Apollo server, so it could make sense to have only the @apollo/federation as a required dependency since it provides the Apollo Federation subgraph specifications (e.g. directives declaration).

[ssukienn]

I think the problem here is that you can use @nestjs/graphql in the scenario where graph is not federated and will never be, thus dependency is optional and not required for such case?

[keadex]

I think that @kamilmysliwiec is referring to the fact that @apollo/federation is an optional peer dependency:

graphql/package.json

Line 96 in 521d8e1

"optional": true

and it is lazy loaded:

graphql/lib/federation/graphql-federation.factory.ts

Line 77 in 521d8e1

'@apollo/federation',

You can use the printSchema() function of @apollo/federation also in the scenario where the graph is not federated since Apollo has forked the code from graphql-js (as reported in the source code) and patched the function to enable also the federation.

[kamilmysliwiec]

The GraphQLModule is a wrapper around Apollo server, so it could make sense to have only the @apollo/federation as a required dependency since it provides the Apollo Federation subgraph specifications (e.g. directives declaration).

We can't make @apollo/federation required as it's not needed for regular GraphQL apps. I'd say we should use the original printSchema for non-federated graphs and the printSchema from @apollo/federation (lazy loaded) for Federation-based apps

[ssukienn]

@keadex I tried your solution and now in my generated federated subgraph I indeed get federated entities/types:

type UserType @key(fields: "uuid") {
  uuid: ID
  ...
}

but the directive @... declarations from the beginning of files which were present earlier in the code-first approach are missing. Is this intended behavior here?

[keadex]

@ssukienn yes, it is an intended behavior. The federated subgraphs do not need the declaration of that directives since Apollo Server is already compatible, as reported in the Apollo Federation documentation:

"This content is provided for developers adding federated subgraph support to a GraphQL server library, and for anyone curious about the inner workings of federation. It is not required if you're already using a subgraph-compatible library like Apollo Server."

In fact in the schema first approach, the Nest.js documentation does not mention the need of that directives: https://docs.nestjs.com/graphql/federation#schema-first

[endroca]

@ssukienn yes, it is an intended behavior. The federated subgraphs do not need the declaration of that directives since Apollo Server is already compatible, as reported in the Apollo Federation documentation:

"This content is provided for developers adding federated subgraph support to a GraphQL server library, and for anyone curious about the inner workings of federation. It is not required if you're already using a subgraph-compatible library like Apollo Server."

In fact in the schema first approach, the Nest.js documentation does not mention the need of that directives: https://docs.nestjs.com/graphql/federation#schema-first

Not necessarily. To publish the subgraph in apollo studio to generate the composition of the supergraph, I need to pass the directives. In the supergraph contains the relationships

https://www.apollographql.com/docs/rover/subgraphs/

[ssukienn]

@kamilmysliwiec @nestjs/graphql v10 is not fixing this behavior. Do you plan to fix it for the apollo driver or is there some other resolution?

[kamilmysliwiec]

Let's track this here #2059

[keadex]

@ssukienn yes, it is an intended behavior. The federated subgraphs do not need the declaration of that directives since Apollo Server is already compatible, as reported in the Apollo Federation documentation:
"This content is provided for developers adding federated subgraph support to a GraphQL server library, and for anyone curious about the inner workings of federation. It is not required if you're already using a subgraph-compatible library like Apollo Server."
In fact in the schema first approach, the Nest.js documentation does not mention the need of that directives: https://docs.nestjs.com/graphql/federation#schema-first

Not necessarily. To publish the subgraph in apollo studio to generate the composition of the supergraph, I need to pass the directives. In the supergraph contains the relationships

https://www.apollographql.com/docs/rover/subgraphs/

Here we were talking about "standard" directives like

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

These directives could be omitted if using a subgraph-compatible library like Apollo Server as reported in the Apollo Federation documentation.
All the other directives are generated.

Actually I have different microservices subgraphs (https://github.com/keadex/keadex-einaudi) successfully published on Apollo Studio (you can also query: https://keadex.io/graphql) without these optional directives:

[ahmad-punch]

Let's track this here #2059

Any update on this?