Juniper: GraphQL schema stiching

[Type1J]

Is your feature request related to a problem? Please describe.
I would like to be able to specify that part of my schema is found on an upstream server, and I'd like it updated when an upstream server updates.

A clear and concise description of what the problem is.
I can't combine my microservices without using Apollo Server.

Describe the solution you'd like
I'd like a way to point to a server to fill in the types that the current server doesn't know about, and then be able to return one of those types in a resolver. I'd also like input types to be proxied through as well.

Describe alternatives you've considered
Apollo Server can do schema stiching, and may be a good starting place for how it should be done in Juniper.

[LegNeato]

We will likely never support this. Juniper's schema is defined at compile time, not runtime.

[Type1J]

@LegNeato It is something that is feasible to do at runtime. The upstream types would be opaque. This is a pass-though feature, not something that would generate types.

[mickdekkers]

You may be interested in Federation if/when that is implemented in Juniper. From my understanding it does what you describe and although it was started by the Apollo team, there is an open specification for implementing it in different languages.

[LegNeato]

This doesn't need to be in Juniper though, right? From what I know (not much!) It is probably handled by a higher level that chooses this part of the graph -> call juniper::execute(), other parts of the graph, do X.

Am I thinking about it wrong here?

[mickdekkers]

@LegNeato I'm afraid I'm not very familiar with Juniper or with the Federation spec, but I'll try to answer your question as best I can. Generally speaking, Federation consists of two parts: a _gateway_ and a number of _implementing services_. The _gateway_ implements the higher level logic that determines which implementing services to call for each part of the graph, which I think you're referring to.

I think being able to create a Federation _implementing service_ using Juniper would be a great start. This alone would deliver a lot of value as it would let anyone write GraphQL microservices in Rust as part of a Federation graph.

While certainly nice to have, the Federation gateway doesn't need to be implemented in Rust initially. Because Federation is based on a specification, people can use Apollo's Federation Gateway Node.js package until someone decides to implement the gateway spec in Rust. Either way, I agree the gateway probably doesn't need to be in Juniper.

There was some discussion in #376 about what changes to Juniper are required to be able to create a Federation implementing service, specifically these two comments.

[Type1J]

@mickdekkers You are correct, I believe Federation is better than stitching, but I didn't know of its existence until your comment. Then I saw this: https://www.youtube.com/watch?v=ra5WuUvQRIM The federation gateway can be a different crate.