Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Federated Schemas From Existing Schema #4310

Closed
wants to merge 13 commits into from
Closed

Conversation

abernix
Copy link
Member

@abernix abernix commented Jun 25, 2020

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
Copy link
Member Author

abernix commented Jun 25, 2020

@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
Copy link

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
Copy link
Member

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
Copy link
Contributor

tot-ra commented Sep 7, 2020

any progress on this?

@stijnbernards
Copy link

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
Copy link

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

@glasser
Copy link
Member

glasser commented Mar 30, 2022

@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.

@glasser glasser closed this Mar 30, 2022
JS Federation/Gateway πŸ‘‰ New Repo automation moved this from PRs (Lingering) to Done Mar 30, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023
@trevor-scheer trevor-scheer deleted the re-open-j-3013 branch April 21, 2023 16:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants