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

Apollo Federation support #148

Open
jferrettiboke opened this issue Jun 1, 2019 · 8 comments

Comments

@jferrettiboke
Copy link

@jferrettiboke jferrettiboke commented Jun 1, 2019

Apollo Federation was open sourced a few days ago by Apollo team. I would like to know if there are plans to integrate Apollo Federation into Nexus in some ways. I just pretend to discuss deeper how this would look like.

I think the way that Nexus provides to extend types is similar to what Apollo Federation does. However, Apollo Federation allows us to create a gateway from different URLs (other GraphQL servers as services) and each URL is a service running independently. I would like to discuss this with some of you guys because doing things in a similar way is easier to maintain and it's better for teams at scale.

The good thing about this is that every team can use the programming language they want (I read somewhere that Apollo plans to expand to other programming languages), and using the gateway in Apollo Federation, all URLs can be merged at once easily and clients will see all graphs connected. Think this like a microservices pattern for GraphQL services.

Nexus is great, but if we try to implement everything within the same server, it will not provide freedom to teams since everything must be done in the same language because Nexus has no ways yet to connect easily to other GraphQL services. In an attempt to mitigate this, I created an issue in prisma/nexus regarding plugins, but it is still in discussion.

Also, running a solo-server using serverless is not efficient and costs are higher. We use Zeit Now and we like to split everything as much as we can so that we are pretty sure that once a function is called, it only does one thing (but very well). This scales so well. With Apollo Federation, you can have as many servers as services you have, plus the server which acts as a gateway.

I think having something like this is a big plus. We can discuss this as much as you want, guys. I would be more than happy to contribute to the future and success of Nexus.

@tgriesser tgriesser added the question label Jun 3, 2019
@tgriesser

This comment has been minimized.

Copy link
Collaborator

@tgriesser tgriesser commented Jun 3, 2019

Not yet, but I am interested in taking a look and seeing what the opportunity for integration might be here - been on vacation the last week or so, so I'm just getting caught up, haven't had a chance to take a look at the specifics of how Apollo Federation is spec'ed to work.

I created an issue in prisma/nexus regarding plugins, but it is still in discussion.

Interested to see what you think of the changes merged in #143 and if it'll address anything you're looking to do re: plugins

@Nayni

This comment has been minimized.

Copy link
Contributor

@Nayni Nayni commented Jun 4, 2019

After reading through the current Federation spec I think there is a great opportunity to build additional functionality on top of nexus to adhere to the Federation spec and allow building these types of schema's.

Most of the spec is actually fairly straight forward, I think implementing the __resolveReference resolver is rather trivial. The only thing that is a little more clunky is the extra work that is needed to provide the schema with additional meta data for the federated graphs. Creating additional types on the schema (as described in the spec) is fairly doable I only dislike one detail of the spec in it's current form, which is that the _service field is a String that has to return a fully printed schema SDL with the federated directives attached at the right locations. I think this is where it gets tricky in approaches that start from code-first. In theory this is possible but it requires additional mechanisms to re-construct the schema, attached all the directives in their corresponding locations and print this schema, coming a code-first approach this is harder to do because we don't have the fully decorated original schema like an SDL-first approach.

Because I am rather interested to hear what their idea and vision is behind this printed SDL approach. Since the printed SDL is mainly used for meta data I feel there is an opportunity to put this meta data in the schema in a more conventional way which would be easier to construct in code-first approaches.
Out of personal interests I opened a ticket already at apollo: apollographql/apollo-server#2769 to discuss this.

@brafdlog

This comment has been minimized.

Copy link

@brafdlog brafdlog commented Sep 7, 2019

Any updates on this?

@0xR

This comment has been minimized.

Copy link

@0xR 0xR commented Oct 10, 2019

You can add federation to you nexus schema using graphql-transform-federation. It will not give you the build time type safety that nexus does, but it does perform strict checking on startup.

Let me know what you think.

@jhalborg

This comment has been minimized.

Copy link

@jhalborg jhalborg commented Oct 21, 2019

Good work @0xR ! 👏 It look functional, but I think it'll be a bit awkward at scale. What do you think about the approach @tgriesser ?

@0xR

This comment has been minimized.

Copy link

@0xR 0xR commented Oct 21, 2019

I agree it's awkward at scale, I see it as a temporary solution until nexus has better federation support.

However, for situations where you don't have control over your schema it is the only solution. For example a managed graphql service or generated graphql schemas.

@nayaabkhan

This comment has been minimized.

Copy link

@nayaabkhan nayaabkhan commented Nov 12, 2019

Just in case if someone wants to see it in action: https://github.com/nayaabkhan/nexus-federation-example. Hoping to evolve the example further with complex cases and finding patterns to use it at scale (e.g. having separate objects in each type and merging into a final configuration for transformSchemaFederation).

Also, something to be aware of 0xR/graphql-transform-federation#1 when using it with Nexus.

@LexSwed

This comment has been minimized.

Copy link

@LexSwed LexSwed commented Nov 21, 2019

I wanted to implement simple schema stitching and old way is now deprecated in favour of Federation. So with nexus the only way to use is through the https://github.com/0xR/graphql-transform-federation
The example for federated schema with the gateway is ok, but I don't need a gateway, I just need to federate my schema within one server instance.
So buildFederatedSchema from @apollo/federation won't work, e.g.:

buildFederatedSchema([Account, SomethingElse].map(schema => parse(printSchema(schema))))

if Account is:

export default transformSchemaFederation(schema, {
  Query: {
    extend: true
  },
  Account: {
    keyFields: ['id'],
    resolveReference(reference: any) {
      return {
        id: reference.id
      };
    }
  }
});

Because it fails to federate Query.
It just weird to see that such mature Apollo moves slowely in support of other tools for building something on top of it, it's been a while since Federation was open sourced....

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