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

Support for Apollo Federation #351

Open
voslartomas opened this issue May 31, 2019 · 12 comments

Comments

@voslartomas
Copy link

commented May 31, 2019

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

@19majkel94

This comment has been minimized.

Copy link
Owner

commented May 31, 2019

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 🔒

@19majkel94 19majkel94 closed this May 31, 2019

@voslartomas

This comment has been minimized.

Copy link
Author

commented Jun 1, 2019

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

@19majkel94

This comment has been minimized.

Copy link
Owner

commented Jun 1, 2019

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.

@19majkel94

This comment has been minimized.

Copy link
Owner

commented Jun 2, 2019

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

This comment has been minimized.

Copy link

commented Jun 18, 2019

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

@19majkel94

This comment has been minimized.

Copy link
Owner

commented Jun 19, 2019

@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

This comment has been minimized.

Copy link

commented Jun 19, 2019

@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

This comment has been minimized.

Copy link

commented Jun 19, 2019

prisma/nexus#148 for reference

@19majkel94

This comment has been minimized.

Copy link
Owner

commented Jun 19, 2019

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

This comment has been minimized.

Copy link

commented Jun 19, 2019

@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

This comment has been minimized.

Copy link

commented Jun 19, 2019

Another issue to help solve code first libraries: apollographql/apollo-server#2769

@j

This comment has been minimized.

Copy link

commented Jun 19, 2019

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, :(

@19majkel94 19majkel94 added this to the 2.0.0 release milestone Jun 19, 2019

@19majkel94 19majkel94 added this to Backlog in Board via automation Jun 19, 2019

@19majkel94 19majkel94 reopened this Jun 19, 2019

@19majkel94 19majkel94 changed the title Are you planning to implement Apollo Federation? Support for Apollo Federation Jun 19, 2019

@19majkel94 19majkel94 self-assigned this Jun 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.