Add support for federation

[phillip-kruger]

Might be a lot of work, but let's consider support for federation

https://www.apollographql.com/docs/federation/managed-federation/overview/

[chet20r]

Thanks Phillip, I think Federation support would be really helpful given organizations adopting microservices pattern. Especially with large organizations with varied technology stacks who want to have a single unified data graph combining multiple microservices on different technology platforms.

There is already a support for federation on the JVM via apollo federation-jvm package. Probably worth looking if that can be leveraged here?

[t1]

This is about services taking part in a federation, right? Writing a federation gateway is a completely different and much bigger topic. I've read several blogs and watched several talks trying to understand esp. the difference between Schema Stitching and Federation. For me, this blog post explained it best.

My ultra-short summary: Schema Stitching works with custom code in the Gateway that hooks the endpoints together. While this approach starts very simple, complexity grows exponentially, as there is a single point that has to know about all connections. Federation OTOH distributes this responsibility to the separate services, e.g. a user service only knows about the User type, while a review service extends the User type with a reviews: [Review!]! field while only knowing about the id of the user. This and a few more things is done with quite flexible directives; and the gateway then does all the Federation magic on a generic level.

[t1]

Maybe it would be sufficient to create a separate library like smallrye-graphql-federation that contains the required types and some custom directives (#628)? Then the core engine nor the spec wouldn't need to know about federation... which currently is actually quite Apollo-proprietary, or is there any other implementation of the gateway?

[t1]

The correct link to start from is https://www.apollographql.com/docs/federation/federation-spec/

The managed-federation link in the description is about the advanced federation gateway in the Apollo Studio product that manages the services with a registry instead of having to list them manually before startup of the gateway.

[t1]

I found that if we really want to support federation with an extension (i.e. a library you can include, not something built directly into the server implementation), we not only need custom directives (#628 for @external, @key, @provides, @requires, and @extends), we also need:

• Unions (Union Types #400 for _Entity); this even has to be dynamic, as the union is the list of all types with a @key directive.
• Custom scalars (MP#94 for _Any and _FieldSet); _Any is a complex scalar (which is an oxymoron in my eyes).

[t1]

I've started some experiments and pushed them here. There are many prio A TODOs left, but it works as a PoC!

I'd love to hear your feedback.

[phillip-kruger]

Thanks @t1 ! I'll have a look a.s.a.p

[t1]

As mentioned in the meeting yesterday, there is one major issue open: a type used as a @FederatedSource argument is not automatically added to the schema, so as a workaround I have to define something like @Query public Film dummyFilm() { return null; }.

[t1]

It could be possible that #312 could help to fix this last priority A todo.

[phillip-kruger]

Can we maybe discuss here (again) why can we not use @Source ?

[t1]

why can we not use @source ?

You mean instead of @FederatedSource? I actually haven't thought about that before. It could work and fix the problem with registering the type. But we'd have to replace the local resolver logic. I'm not sure how to do that.

[phillip-kruger]

Yea, so the class needs an @External right ? So we should be able to figure it out, but it might need some changes in SR impl module

[mistreckless]

What is current status for the federation support? Can I use it with quarkus in expiremental/alfa status on my own risk? There are still no federation quarkus extension #15386.

[t1]

It currently works as an alpha in JEE containers, but not in Quarkus. We're still working on the Quarkus Extension, but there was not much progress lately. Do you want to support?

[shmulik-klein]

@t1 I would really like to help with the Quarkus extension, where can I start from?

[t1]

Maybe @phillip-kruger can give you a hint?

[phillip-kruger]

I'll be honest - I am not sure. I am not sure if this would be a new extension, or build into the current one. I think the current one. So maybe start by playing around with that ?

[shmulik-klein]

Thanks @phillip-kruger.

@t1 @phillip-kruger Just to make sure that I understand it correctly - quarkus-smallrye-graphql Quarkus extension, generates the graphql schema at build time (Augmentation), so it can't work with smallrye-graphql-federation-runtime as the later observes to the schema creation and adds to it the entities required to make it a federated schema? - meaning, you can only use it entirely as a Quarkus extension or entirely as a regular dependency, but can't make a mix of those?

Also, isn't the extension resides on quarkusio/quarkus repository?

[ntkoopman]

What's the status of this? Is there anything I can help with?

[phillip-kruger]

Hi @ntkoopman ! Thanks for offering to help. As far as I know basic support is available in Quarkus. The outstaning items is getting the reactive part to work correctly (or at all). So interpret Multi/Uni and execute those on the eventloop. @t1 @jmartisk can you comment ?

[MightyPixel]

Hi everyone!
I've saw this page in the apollo website. Does it make sense to add a table for smallrye-graphql to keep track what is supported?

[t1]

@phillip-kruger & @ntkoopman: Sorry for not responding before. We currently don't use it in my project, so I can't invest a lot of time on this at the moment. Your summary of the current status looks quite like what I remember it to be. I actually tried to fix the reactive stuff, but gave up. I suppose my brain is just not made to work with reactive logic. I'm soooo glad that Project Loom is coming to save me 😁

@MightyPixel: That would be great. We would need to run the specified tests against our implementation. That would be an essential step forward. Maybe you can get them running (and failing)?

[robp94]

Reactive should work at least Unis.