Build Federated Schemas From Existing Schema

[abernix]

This re-opens @j's #3013, which was closed inadvertently by the process described in #4304. 😭 Since the source branch had been deleted, it was one of only a couple PRs I couldn't re-open. Thus, this new PR needs to be created.

(To be clear: I certainly don't mean to take credit for it. This is purely organizational/housekeeping. I re-opened it by pulling the ref that GitHub stores on refs/pull/3013/head (the old PR; still exists even when the PR author removes the branch) using git fetch origin pull/3013/head && git checkout -b re-open-j-3013 FETCH_HEAD && git push origin ✨ )

Hello!

So I'm implementing federation in type-graphql and saw that there's some improvements that I feel will make 3rd party libraries not using typeDefs & resolver maps for creating schemas.

This adds the ability to pass in an existing GraphQLSchema object and does the following if the argument passed to buildFederatedSchema is an instance of GraphQLSchema:

1. Iterates over the schema's type's to get a map of the "resolveReference" functions
   1a. First checks type's resolveReference property
   1b. Checks if type has a field named __resolveReference (also deletes this field after saving the function)
2. Creates the federation specific object types
3. Adds the resolvers found in the schema using addResolversToSchema

Everything else stays the same. I ended up creating a utility function to all of the tests to automatically test a wrapped version of the federated schema as well as included one manual one.

This will make federation support super easy for projects like type-graphql instead of doing printSchema hacks, converting to typeDefs and plucking resolvers out to then be re-converted to SDL and schema, etc. We can then not have federation as a dependency but instead require @apollo/federation on our own app and expose the federated server.

References:
MichalLytek/type-graphql#369

Example Usage in type-graphql: MichalLytek/type-graphql@9bbed68

[abernix]

@trevor-scheer Could you share some thoughts / direction on what the next steps here would be? We discussed the idea of switching to extensions somewhat recently when we were (roughly?) discussing #4263, and that would seem to tie back to this issue and desired functionality for existing schemas.

It is my belief that, since graphql now supports extensions in newer versions (originally discussed in graphql/graphql-js#1527), we would need to change our own representation of executable, composed schemas to use the new extensions object and then get this PR cleaned-up to use that.

[Superd22]

Just for reference, I currently don't have time to work on this anymore, but i did copy j's orignal branch here : https://github.com/Superd22/apollo-server/tree/build-from-schema-2

[trevor-scheer]

Usage of extensions has landed as of #4313. I've grown unfamiliar with the changes introduced in this PR, but I'd be happy to revisit them if anyone is interested in picking up this work. Please feel free to ping me either here or in a new PR with any questions!

[tot-ra]

any progress on this?

[stijnbernards]

Hi @trevor-scheer,

I'm interested in picking up this PR. I've taken a look at: #4313
And it doesn't seem to conflict with any changes made in this PR.

I'm willing to fix the merge requests and tests as I would really love to have this feature 👍

[mengqing]

Just wondering if there's any updates to this PR? Would definitely love to have the ability to reuse existing schema

[glasser]

@mengqing Actually, the code for this PR no longer lives in this repository. It's in the https://github.com/apollographql/federation/ repository now. We've also extracted the parts of @apollo/federation specific to running a subgraph into @apollo/subgraph within that repository, and renamed the function to buildSubgraphSchema, and changed its implementation in some ways.

I'm going to close this PR since it's definitely not going to get merged in this repo :) @trevor-scheer can advise as to whether or not it's likely that a new PR to add GraphQLSchema support to buildSubgraphSchema would be likely to work well.