buildFederatedSchema with existing GraphQLSchema

[j]

I'm trying to implement apollo-federation in type-graphql library which uses GraphQL*Type to construct schemas. Is it possible to build convert/build a federated schema from a GraphQLSchema? It seems like these libraries will have to convert to outputting SDL instead of using graphql-js directly.

[JacksonKearl]

You can get from a normal schema to a federation-capable one through the steps on our federation specification docs. In short, you just need to add a few fields and their resolvers to the schema, and define some directives.

An alternative approach could be to use type-graphql's buildTypeDefsAndResolvers function, which will (expectedly) build typedefs and resolvers given a type-graphql-style "Resolver Class".
However, the generated typedefs and resolvers aren't quite the correct type to be passed straight to buildFedaratedSchema:

• The typedefs can be passed through gql to convert them from string to DocumentNode. Easy enough.
• It looks like the only difference between type-graphql's ResolversMap and our GraphQLResolverMap is the addition of a top-level "ResolverOptions" construct on their side. I'm not quite sure what that does, but if we can just filter it out the types should be identical.

I'd like to play around with this a bit more, but it looks like type-graphql's examples have suffered a bit of bit-rot and no longer build. If you have a small sample project to work with we might be able to get something figured out!

[j]

@JacksonKearl I just cloned the repository and copy / pasted a test and was going to add annotations to define federated schema. Would you say your first approach is best vs bringing on gql dependency? Also, I was just getting lost with how "decorators" are added to gql typedefs that apollo takes in. I can't find documentation on that. Using apollo-federation might be best since changes to federation can be instantly implemented on both sides.

[j]

I was converting our type-graphql project over to plain federation and stopped really fast. Even using typescript generators for graphql types and resolver types, I wanted to stab my eye bringing it all together, haha. I decided to try to help put it into type-graphql myself.

[j]

PS. I was going about the manual way, but I'm unsure how to properly add directives to an ObjectType.

[JacksonKearl]

I got part of the way doing this myself, before I ran into the same blocker you're having regarding directives. Looks like type-graphql does not support directives at all, and this is a known issue: MichalLytek/type-graphql#77. I don't think you'll be able to implement federation without those directives (federation is more or less built on directives), so you may need to wait until that issue is resolved.

Might I suggest Apollo Client instead? 😉

[JacksonKearl]

Ah! I see you're already active here: MichalLytek/type-graphql#351

[j]

@JacksonKearl Hey! I started hacking at it and got type-graphql to output a federation type of schema.

The directive hack is here: https://github.com/19majkel94/type-graphql/pull/369/files#diff-48f4a1f7b529a17d4579df20f8af7af1R272

And here's a quick test showing that it works (well prints schema correctly): https://github.com/19majkel94/type-graphql/pull/369/files#diff-b0c36f08a566dd0298fff8e07447781b

I mimic'd the demo reviews service.

I'm not sure if I break schema by using astNode instead of extensionASTNodes. I'd think I should use extensionASTNodes but apollo federation doesn't pull directives unless astNode IS defined and using typescript, I can't have it be an empty object (https://github.com/apollographql/apollo-server/blob/master/packages/apollo-federation/src/service/printFederatedSchema.ts#L170).

That directive issue you listed is so people can use directives more as middleware / validation / etc, whereas I believe federation just uses them for referencing schema and doesn't do anything on a resolver level with them? So I thought I could implement them directly for now to see if I can get it to work. I believe I could create a __resolveReference field resolver within type-graphql, so

I'm not too sure where to go from here though, haha. I was going about it the "manual" way you mentioned instead of using the buildFederatedSchema route.

/cc @19majkel94

[jbaxleyiii]

Thanks very much for reporting this! We think this is a great idea, and would definitely review a PR. If you (or anyone else) is interested in working on this, that would be great - thanks!

[MichalLytek]

It looks like the only difference between type-graphql's ResolversMap and our GraphQLResolverMap is the addition of a top-level "ResolverOptions" construct on their side. I'm not quite sure what that does, but if we can just filter it out the types should be identical.

@JacksonKearl
type-graphql's ResolversMap is designed to work with other tools, like graphql-tools - I've basically copied their types and refactored them a bit. The ResolverOptions are responsible for handling subscribe instead of resolve (not supported in federation) as well as __resolveType and __isTypeOf for unions and interfaces.