graphql-rust
Federation specification implementation
I don't know if it is too early to implement federation specification in juniper but please can you add it to your road map. Basically it is a way to composable GraphQL schemas using primitives (provided by @apollo/federation package) that replaces schema stitching.
- https://www.apollographql.com/docs/apollo-server/federation/introduction/
- https://www.apollographql.com/docs/apollo-server/federation/federation-spec/
- https://github.com/apollographql/apollo-server/tree/master/packages/apollo-federation
- https://github.com/apollographql/apollo-server/tree/master/packages/apollo-gateway
I don't think we would ever implement this as it is non-standard. Potentially we would take a PR with a an optional feature though!
Please can you consider implementing just the additions:
Federated services will need to implement the following additions to the schema to allow the gateway to use the service for execution:
scalar _Any
scalar _FieldSet
# a union of all types that use the @key directive
union _Entity
type _Service {
sdl: String
}
extend type Query {
_entities(representations: [_Any!]!): [_Entity]!
_service: _Service!
}
directive @external on FIELD_DEFINITION
directive @requires(fields: _FieldSet!) on FIELD_DEFINITION
directive @provides(fields: _FieldSet!) on FIELD_DEFINITION
directive @key(fields: _FieldSet!) on OBJECT | INTERFACE
# this is an optional directive discussed below
directive @extends on OBJECT | INTERFACE
https://www.apollographql.com/docs/graphql-tools/schema-directives/
I think these additions will be enough to build federated graphql microservices.
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.
Federation is fully declarative and doesn't require any user code to be running in the gateway.
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.
I would be happy to send a PR but I don't trust my Rust skills yet.
Well, it's not quite true. These additions are required, but not sufficient. We still need a way to define these external keys for fields for every gql object. Given it's not in the spec, I agree with the opinion that it must be behind the feature flag. I rather wonder would we need to wait until #138 is done.
I think that having a way to declare custom directives should be added to juniper, as it is part of the spec https://spec.graphql.org/June2018/#sec-The-__Directive-Type
For anyone trying to implement a federated graphql server in rust today, it looks like it's possible with async-graphql. Here's a blog post demonstrating how to do it.
Hello maintainers, is this something you guys have in your plans? Considering federation seems to be very good way to architecture microservice graphql APIs
@cyberhck yes, federation is definitely in our plans. Contributions are welcome, though, as the project has quite a low bandwidth at the moment.
I actually really loved Rustlang, and wanted to give it a try with juniper, but federation is a must have for me, which is kinda why I'm not using rust at the moment, while async-graphql is supporting it, unfortunately I'm afraid both graphql servers project doesn't have enough bandwidth.
I'd love to contribute unfortunately I literally have only made hello world in rust and I think me trying to help would be worse than you guys doing it yourself, I have done a small part of federation in C# myself though, there are certain things we need to do I'm sure we can get done soon :)
How does the recent license change for Apollo Federation 2 to Elastic License 2 impact future plans to have juniper support federation?
I'm curious of switching from golang gqlgen to rust juniper but this is a must for me as well
I'm also using golang gqlgen right now, and I was also exactly where you are right now.
If it did support, I'd have migrated already, unfortunately I don't even know how to start to contribute :smile:
@vuldin from what is written in the blogpost you've linked, there shouldn't be any troubles with the license, until the juniper maintainers will decide to sell it as a "managed service" 😅, which is unlikely to happen.
We would be able to keep the integration in a separate crate, where being explicit about license complications, so it would be transparent for library users to use federation or not.