Announcing Apollo Federation 2

Announcements
1

Deep Space II - R (2)
Deep Space II - R (2)1600×800 231 KB

We’re excited to announce Apollo Federation 2, an evolutionary step forward that builds on the success of the original version with an improved shared ownership model, enhanced type merging, and cleaner syntax for a smoother developer experience. It’s backwards compatible, requiring no major changes to your subgraphs. Try the alpha today!

Apollo Federation is an architecture for declaratively composing APIs into a unified graph. Each team can own their slice of the graph independently, empowering them to deliver autonomously and incrementally.

Designed in collaboration with the GraphQL community, Federation 2 is a clean-sheet implementation of the core composition and query-planning engine at the heart of Federation. We’ve improved the developer experience by adding deeper static analysis, cleaner error messages, and new composition hints that help you catch errors sooner and understand how your schema impacts performance. With the new version, we’ve streamlined common tasks like extending a type and simplified advanced workflows like migrating a field across subgraphs with no downtime.

Following in the footsteps of modern infrastructure projects like Elasticsearch and MongoDB, we’re moving Federation 2 to the Elastic License v2 – an open and permissive license with few restrictions. This change shouldn’t affect the vast majority of our community, and the new code is still free to use and modify. Subgraph packages will remain MIT, as well as the 0.x Federation packages, so there are no changes to what you’re doing today.

While Federation 2 is backwards compatible, it’s enhanced validation might catch a few things that the original Federation didn’t. Things you’ll be happy to know about!

Read the blog post for more details and let us know what you think!

4 Likes
2

Can someone please release a working tutorial with full code examples. That can be run locally after using git clone

Preferably with metasyntactic variables like foo and bar. The documentation is not good right now, I will help write about Apollo Federation, Although it is incredibly difficult to learn right now for an outsider. Please get in touch with me if you want me to explain more. The documentation/ quick starts have a lot of space for improvement.

The main problem is the examples are all piecemeal and there isn’t a full working example that can be run locally and inspected/ iterated on.

Or at least there isn’t one that I have found, combing through the documentation and google.

1 Like
3

Nice, so it looks like basically every single pain point I mentioned in Feedback thread: Future deprecation of serviceList in ApolloGateway was not resolved in any way?

What was the purpose of giving feedback if it feels like it was 100% ignored?

I gave feedback because it seemed like we would have a lot of trouble adopting rover, and seeing this, it looks like we will have a lot of trouble adopting rover, assuming we even use it.

1 Like
4

@Milldrew – here it is: GitHub - apollographql/supergraph-demo-fed2: Demo for Federation 2

5

@kevin-lindsay-1 we’re working on solutions to your feedback, stay tuned!

1 Like
6

I appreciate the heads up, I look forward to hearing about those ideas, as I know just because I give feedback and possible ideas doesn’t mean that what I might choose from a design standpoint is good for the product or community.

I apologize for the rather rude way my candor sounds in retrospect, however that doesn’t mean that I’m not still nervous about the product direction of federation. I have no real insight into product direction, which is arguably as it should be, or maybe I’m missing a roadmap here.

The reason that I, and I imagine a few others, are nervous about this is that I recognize that there’s a manageable, but nonetheless existent conflict of interest between being open-source and closed-source/managed services. The thing that I’m mostly afraid of, especially since the feedback thread, is that Apollo might saw the legs off of its free tables in order to make the paid tables look more attractive. Hopefully that never happens, and I don’t think I’m overly worried about it, but it is a concern.

For the record, my team totally uses paid tools, including the paid version of otherwise free stuff. The only reason why we don’t use Apollo’s managed features is that they’re honestly more of a hindrance to us, locking us into what is otherwise an open-source landscape for features that are currently mostly CI and observability tools, and we’ve already got those bases covered by GitLab and DataDog, respectively.

I understand that Apollo is a business, and what I can say is that our company, at least, is much more likely to pay for licensed tools that we can use inside of our existing infrastructure and workflows than we are to pay for managed services in general. We would probably be willing to pay for managed services if we didn’t have to actually build all the servers and host them ourselves, but if we’re gonna build and manage our own servers and schemas, we’re probably not going to give them to a managed service provider just to do things like “check these files for breaking changes”. We might, however, pay for a “pro” version of a tool to do those special features.

In other words, with the types of services that Apollo offers right now, it would be a much easier sell to bring Apollo’s services to us via licenses than it would be to bring us to Apollo’s services via half-managed services.

lol forget my 2 cents, here’s a dollar.

4 Likes
7

Hey @kevin-lindsay-1 — I’m sorry it feels this way! Just to be clear, we’re still working on processing feedback and building the right solution for the eventual deprecation of serviceList. The things we announced thus far for Federation 2 are other improvements and work that we had in flight long before we started the thread about deprecating serviceList. I for one hope you don’t feel ignored given the feedback I’ve already engaged with on that thread, and I suspect you’ll be happy with the solution we do eventually land on for that — but that’s still stuff we’ve yet to finalize.

Since the “Federation 2” stuff we’ve announced thus far isn’t inclusive of declaring the end-game for serviceList I think that — practically speaking — we’ll probably keep discussing those things on the thread where we started. For now the serviceList stuff is still present in Federation 2.0 as it was in previous versions. We’ll hopefully be getting back to those designs – and a solution — soon, and we’ve definitely been thinking about it in our discussions. Hopefully we can get those discussions going publicly again soon and I think we’ll maintain a great deal of flexibility in what we do come up with.

1 Like
8

Just to underscore what @abernix said – we really appreciate all the great feedback on the serviceList thread and have been actively working on a solution. @trevor.scheer has a proposal in apollographql/federation#1180 for a more flexible and reactive serviceList option that supports more advanced scenarios in a more modular way. We’d love to hear if this works for you in the GitHub issue and the serviceList thread.

If all looks good, we can add this to the original Gateway and the 2.x Gateway since we are maintaining both in parallel for a smooth migration over the coming months.

We remain committed to ensure Federation works for everyone – not just with managed Federation (which is free btw), but also with unmanaged Federation which has always been free and remains free to use, modify, and distribute – including Federation 2.

We’ve also polished up the Federation 2 alpha docs which now include a link to the Federation roadmap, so would love to hear your early feedback on the Federation 2 alpha, thoughts on the Federation 2 preview, and additional things you’d like to see! :pray:

1 Like
9

I really hope there will be a way to use subscriptions in federated graphs v2 without putting it in a separated subscription service.

2 Likes
10

Thanks @timon, appreciate your feedback! While many people want to isolate the subscriptions load from normal query and mutation traffic in the main Gateway and to scale them separately, we appreciate that for your use case it would be better to have all 3 in the same Gateway instance. We’ll take this back to the team and see what we can do – and note we have a Using Subscriptions in Federation thread going for additional feedback. :pray:

11

We’d love additional feedback on Federation 2 and and more info about your current Gateway deployment and customizations so we can factor that into the Apollo Router design. If you have a few minutes here’s a survey that would help us ensure all your key use cases are met ! :pray:

12

Thanks for all the improvements with Federation2. We have started using it in our project and we are trying to find a solution for one of use-case, which is
If 2 federated services have the “Query.user” defined can we prioritize such that the gateway calls one service than the other? If yes can you tell us how we can do that? I remember in graphql summit you talked about @override but I don’t see it documented anywhere.

13

Thanks @Aneeth!

The primary use case we’ve heard for @override is field migration across subgraphs, so we’re leaning toward calling it @moving(to: "subgraph").

It hasn’t been implemented yet but would love everyone’s feedback on the proposed design for `@moving(to: “subgraph”) in Add a mechanism to force query-planner choices (tentatively `@override`) · Issue #1177 · apollographql/federation · GitHub