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

jferrettiboke opened this issue Jun 1, 2019 · 2 comments


Copy link

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


This comment has been minimized.

Copy link

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


This comment has been minimized.

Copy link

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.

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