Mandi Wise wrote a great article on how to do subscriptions with Federation back in May '21. If you haven’t seen it yet, it’s definitely worth checking out.
Would love to get more feedback on this approach (which has many benefits) and alternate proposals for how folks would like to see subscriptions handled in Federation. 
Super grateful that Mandi Wise wrote that article and published the code on Github, would have been lost without it. That being said the federation-subscription-tools repo could use some love, there’s several PRs out by the community to fix some of the errors but no active maintainer. I was really hoping to see first-class support for subscriptions with the announcement of Apollo Federation 2.
As far as the approach, I think having a standalone subscription service is probably the right approach, but I think there’s room for improvement in the actually implementation. The current implementation example doesn’t allow for introspection over http/s. I’m working on a alternative approach right now based on Mandi Wise’s project but where the subscriptions lives along-side the federated gateway
Hi Jake.
I echo your sentiments around the work that Mandi has done around federated subscriptions. It has been a lifesaver in a project I am currently working on. I am curious if you’d like to chat about our current implementations and see if we can help each other and the greater community.
I do like the approach of handing subscriptions as a concern, but it comes with some drawbacks. For example, we use the gateway as entry point to all of our services, meaning the gateway also applies the context, handles auth concerns etc. With the subscription service as another entry point, we have to outsource auth concerns into a service and apply it in the subscription service as well as the gateway. This is also not so beneficial regarding performance. We could put another gateway in front of both, which feels like an overkill.
I approached this by building one more microservice that stands alongside/on top of gateway. It uses schema stitching and adds subscriptions. So basically my client runs queries and mutations to my gateway, and subscriptions to my subscription service. However there are many downsides of this that are coming up only now when it went to production. If I sent some entity via my PubSub, but I request more than that (for example some relation), that becomes a problem, since I need to use functionality called delegations and perform the entire queries to get that information 
Tbh it really sucks, I also thought that in federation 2.0 we will get decent subscriptions, however from the summit and article I believe that it isn’t coming, right? If there are someone from Apollo let us know guys, can we expect something to be done about subscriptions? Or do we need to look for these workarounds that doesn’t perform well?
Hi Michael, yeah I’d love to chat about our implementations. Hopefully we can help move the needle in making this a bit more seamless for everyone in the community
Hi @jakehewitt, I’ve implemented the Mandi Wise article. Would be great if we could connect to see if we could assist each other… Would you be open to connect?
Let em know
Any info when subscriptions will be handled nicely by Apollo Federation?
