Support for Apollo Federation

[voslartomas]

Is your feature request related to a problem? Please describe. I guess it would be about to add some decorators for @key, @extend etc, to be able to declare federation schema services.

Describe the solution you'd like https://blog.apollographql.com/apollo-federation-f260cf525d21

[MichalLytek]

I guess it would be about to add some decorators for @key, @extend etc

So it's blocked by #77 😞 But when #77 is ready, you would be able to use Apollo Federation with TypeGraphQL without any problem, so no further integration needed 🔒

[voslartomas]

@19majkel94 I see, I've read the issue and saw that you agreed (february) with guys from graphql-js, but not sure what does that mean for current situation? Is it going to be blocked, or something is happening?

[MichalLytek]

I am waiting for changes in GraphL spec and graphql-js that add interchangeability between extensions and directives, so both approaches (SDL and code-first) could be used and handled by universal directives and other tools like prisma or apollo federation.

And @Hossein-s is working on a workaround to modify astNodes that are currently used by all JS tools to consume directives metadata from SDL.

[MichalLytek]

I guess it would be about to add some decorators for @key, @extend etc,

Looks like it's not only about directives but also the extend keyword, which is handled in #228 🔑

[j]

@19majkel94 is it the extend keyword in #228 though? Doesn't #228 do the whole, type User extends BaseType.. The extend keyword in federation goes before the type, it's a way they can make the root graphql service have field calls different services.

[MichalLytek]

@j I know, in #228 I was thinking about both merging typedefs from different file and extend type Foo syntax if it's possible with graphql-js.

Edit: extendSchema exist but I would have to also use graphql-tools to merge the schema with resolvers or find a way to separate the extends to SDL and keeps the field resolvers for unknown fields? Needs some exploration 😕

[j]

@19majkel94 bummer, yeah looks like most "code first" node.js implementations are going to have a rough time from what I was reading. I saw a post of someone requesting a different way of making schemas to make it easier, but I'm not sure what it'd take. Apollo Federation is the next step for our company's infrastructure and will have to move away from type-graphql if support doesn't come to, and that'll be a sad day. :(

[j]

https://github.com/prisma/nexus/issues/148 for reference

[MichalLytek]

Maybe I could just drop building schema using graphql-js and create the SDL string on my own (like in the reflection plugin PoC), and then just plug in the resolvers using graphql-tools to create an executable schema if it's needed (or not in the case of the type-graphql core).

[j]

@19majkel94 that sounds pretty flexible? Also, again, I haven't dug into how to do it within your library. Are you looking at the SDL apollo-federation came up with? Or the actual graphql schema?

Examples: https://pw678w138q.sse.codesandbox.io/graphql (sibling service) https://v368r9ml47.sse.codesandbox.io/ (gateway)

You wouldn't need to do anything that the gateway does, just be able to output what the sibling does per spec.

But just outputting string schema's seems like the most flexible?

[j]

Another issue to help solve code first libraries: https://github.com/apollographql/apollo-server/issues/2769

[j]

Another note I saw regarding "extends". https://www.apollographql.com/docs/apollo-server/federation/federation-spec/

The spec actually supports this:

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

But still looks like a lot of work, :(

[MichalLytek]

I've added an example of apollo-federation (a modified federation demo from @j PR): https://github.com/MichalLytek/type-graphql/tree/20c81f4f7ee82779595002d25784fce3a8ff8b9b/examples/apollo-federation

I will leave this PR open to collect some feedback about the integration. Also in the future I plan to make @typegraphql/federation package with @FederationKey decorator and others like defining resolverReference, etc. 😉

[lgabeskiria]

Hi guys! Thanks for this amazing library! Do you have any ETA when can we expect this feature in production?

[MichalLytek]

@lgabeskiria Have you tried the latest beta release? Without testing and confirmation I won't release "stable" package.

[lgabeskiria]

@MichalLytek will try to provide a feedback this week, thanks!

[Sector95]

Got it working in our (currently) very simple project today, so far so good... Will continue working with it over the next couple of days and will report back as well.

[lgabeskiria]

@MichalLytek tested the feature, looks good to me!

[lgabeskiria]

Hi @MichalLytek is it possible to release this feature as beta release?

[MichalLytek]

@lgabeskiria Have you checked the npm site and typed npm i type-graphql@beta?

[tuxmachine]

Tested the beta release with the GraphQL module in nestjs and works like a charm.

[adamovittorio]

Hi All, I've installed the beta, used the same approach described in the example with buildFederatedSchema and copying in my source code createResolversMap and his dependencies because they are not exported from type-graphql.

It seems to work to me but the schema generated doesn't have the @key annotation.

player.ts

import { ObjectType, Field, ID, Directive } from "type-graphql";

@Directive(`@key(fields: "id")`)
@ObjectType()
export default class Player {
  @Field(_type => ID)
  id: string;

  @Field()
  username: string;
}

resolver.ts

import { Query, Resolver } from "type-graphql";
import Player from "./player";

@Resolver(_of => Player)
export default class PlayerResolver {
  player = {
    id: "123",
    username: "victorious",
  };

  @Query(_returns => Player)
  async me(): Promise<Player> {
    return this.player;
  }
}

schema.graphql

# -----------------------------------------------
# !!! THIS FILE WAS GENERATED BY TYPE-GRAPHQL !!!
# !!!   DO NOT MODIFY THIS FILE BY YOURSELF   !!!
# -----------------------------------------------

directive @extends on INTERFACE | OBJECT

directive @external on FIELD_DEFINITION | OBJECT

directive @key(fields: String!) on INTERFACE | OBJECT

directive @provides(fields: String!) on FIELD_DEFINITION

directive @requires(fields: String!) on FIELD_DEFINITION

type Player {
  id: ID!
  username: String!
}

type Query {
  me: Player!
}

Am I doing something wrong?

[MichalLytek]

@adamovittorio

It seems to work to me but the schema generated doesn't have the @key annotation.

https://typegraphql.ml/docs/next/directives.html

[adamovittorio]

@MichalLytek - Thank you very much, I miss that part 😅.

Regarding buildFederatedSchema, will it be exposed from type-graphql/@typegraphql/federation?

[MichalLytek]

In the future yes, in @typegraphql/federation I think 😉

[adamovittorio]

Hi @MichalLytek, do you have any update regarding @typegraphql/federation, can I help in some way?

[Sector95]

Is #521 expected to change how this is implemented?

ie. Will we be using the @Extensions annotation in some way instead?

[MichalLytek]

@Sector95 In the future yes 😉 Apollo team has to expose a way to build federated schema from existing GraphQLSchema object and use extensions instead of AST directives: https://github.com/apollographql/apollo-server/pull/3013

[SamXDesc]

Tested the beta release with the GraphQL module in nestjs and works like a charm.

Can you provide a demo repository for us?

[tuxmachine]

Can you provide a demo repository for us?

There's a small demo in my fork of the NestJS GraphQL package (PR still open)

https://github.com/tuxmachine/graphql/tree/feat/enable-code-first/tests/type-graphql-federation