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

Feature Request: Support Apollo Graphql Federation #492

Open
StevenACoffman opened this issue Jul 1, 2019 · 15 comments
Open

Feature Request: Support Apollo Graphql Federation #492

StevenACoffman opened this issue Jul 1, 2019 · 15 comments

Comments

@StevenACoffman
Copy link

StevenACoffman commented Jul 1, 2019

Feature Request:

Please consider supporting Graphql Federation. This does not necessarily mean implementing all of the Apollo Federation Spec in this library, but just what would be necessary for someone implementing Apollo Federation to use this library for that purpose.

https://www.apollographql.com/docs/apollo-server/federation/federation-spec/

Background:

We use hundreds of microservices, and a monolithic GraphQL server becomes an unacceptable development bottleneck and single point of failure, so it becomes necessary to divide the graph's implemention into separate parts. We tried schema stitching, but would prefer federation for three reasons:

  1. With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.
  2. Federation is fully declarative and doesn't require any user code to be running in the gateway.
  3. Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.
@bhoriuchi
Copy link
Contributor

this seems outside the scope of this project.

@StevenACoffman
Copy link
Author

StevenACoffman commented Jul 4, 2019

How so? Supporting the parts of the Apollo spec to allow others to use this project to build federated graphql microservices seems pretty in scope.

@bhoriuchi
Copy link
Contributor

Federation is an Apollo spec not a graphql spec. This library implements the graphql spec https://graphql.github.io/graphql-spec/June2018/ which has no mention of federation.

@bhoriuchi
Copy link
Contributor

Actually I apologize. I realize you are just asking this library to support the additions not federation itself. I believe the additions should be in scope

@StevenACoffman
Copy link
Author

No worries, I clarified my request. Sorry for not being more clear from the beginning.

@0xR
Copy link

0xR commented Oct 1, 2019

You could implement federation in a separate library. See for example: https://github.com/0xR/graphql-transform-federation. It takes an existing schema and with some configuration it can add federation support. Note that that is a NodeJS implementation, but I'm sure it could be implemented in Go as well.

If you're ok with running NodeJS you can add federation support to your Go service by using graphql-transform-federation as a middleware service. It can take a remote schema as input as well.

@itmayziii
Copy link

@chris-cp

Is there interest in this library supporting this? I've read the federation spec a couple of times now and it seems at a high level this library would need to support:

  1. _service query would need this library to either support printing the schema as this spec describes or exposing the AST of a schema created with graphql.NewSchema so that another library could handle printing out the SDL.

  2. Stub types could probably already be implemented by another library, but again it would require we are able to read an AST in order to know what fields to implement a stub for. I wasn't able to find a way to get an AST from a schema created with graphql.NewSchema, but I might be overlooking it?

  3. Entities again could probably be implemented in another library provided this library is able to expose its AST so that we can create a union type as described in the spec.

  4. Directives should not need to be implemented as that appears to be entirely handled at the gateway level and not individual federated services.

It seems that this spec could be entirely implemented in another package as long as this package is able to expose its AST. If anyone has any thoughts or feedback I'm interested in hearing them. Also if @chris-cp is interested in supporting this but maybe does not have the time, then I would happy to take a shot and open a PR.

@remorses
Copy link
Contributor

remorses commented May 5, 2020

Anyone knows about any library to handle this?

@StevenACoffman
Copy link
Author

gqlgen has supported it for some time.

@luisdavim
Copy link

Federation is not exclusive to Apollo https://movio.co/blog/building-a-new-api-platform-for-movio/

@MoritzGruber
Copy link

If someone es is looking for this, you can build your own with: https://github.com/jensneuse/graphql-go-tools

@ktutnik
Copy link

ktutnik commented Dec 28, 2021

Any plan to support this feature in the future?

@sumedhamehta
Copy link

sumedhamehta commented Feb 4, 2022

Huge +1! The team at MongoDB also uses this package for our hosted GraphQL API endpoint. It would be a great add-on feature on top of our generated GraphQL Schema and would be valuable to get customers on-board with adopting GraphQL more widely in their organizations in a scalable manner.

@jesse-apollo
Copy link

I took a stab at implementing federation with this library and it seems like the primary blocker here is that we can't specify directives for types (ie, ObjectConfig doesn't support setting directives). It is also non-obvious if it is possible to render an SDL from a Schema object.

dariuszkuc added a commit to dariuszkuc/graphql that referenced this issue Oct 17, 2022
Update type definitions to expose `AppliedDirective`s. **This initial implementation only exposes applied directive as metadata and does not modify runtime wiring to process them**. Exposing directives is a pre-req to enable support for [Apollo Federation](https://www.apollographql.com/docs/federation/) (related: graphql-go#492).

Following the pattern from [`graphql-java`](https://github.com/graphql-java/graphql-java) and [`HotChocolate`](https://github.com/ChilliCream/hotchocolate) where they make distinction between directive type definition (i.e. `directive @foo on FIELD_DEFINITION`, maps to existing `Directive struct` for backwards compatibility) and where directives are actually applied within the schema (i.e. `type Foo @bar { baz @Qux }`, maps to new `AppliedDirective` struct`).
@dariuszkuc
Copy link
Contributor

Hello 👋
If anyone is interested I got a working example integration in https://github.com/apollographql/apollo-federation-subgraph-compatibility/tree/main/implementations/graphql-go

I forked graphql-go/graphql to get my PRs (#651, #652 and #653) merged and created new federation module -> https://github.com/dariuszkuc/graphql/tree/federation

I've also created a tag for easier integration -> https://github.com/dariuszkuc/graphql/releases/tag/v0.9.0-federation

Would love to get some feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests