My app uses Apollo subscriptions quite a lot. I see that updates are required to get this to work with Apollo 3. I’ve looked at the Apollo 3 docs here:
It appears subscriptions are disabled by default. It doesn’t seem likely, but are subscriptions second-class citizens now in Apollo 3?
Subscriptions were already second-class citizens in Apollo Server 2. For example, they weren’t integrated at all with the plugin system which completely ignored them; they were built on top of some not particularly maintained packages like subscriptions-transport-ws; they did not work with Federation; they did not work with Studio usage reporting; etc.
We’d love to make subscriptions into actual first-class citizens in Apollo Server (and the entire Apollo platform) and I’m optimistic we’ll get to it. Until then, you’re welcome to continue using subscriptions-transport-ws directly; the entire support for subscriptions in Apollo Server 2 was about a hundred lines of code stapling subscriptions-transport-ws onto the side of Apollo Server, and we’ve reproduced instructions for doing that yourself in the Apollo Server docs.
Hmmmm… my app actually can’t function without subscriptions. Polling won’t work in my use case. Should I be concerned?
If subscriptions work for your Apollo Server 2 app, they will work just as well for your Apollo Server 3 app. It’s just that the bit of glue code that attaches subscriptions-transport-ws to your schema and Express server will have to live in your app rather than inside Apollo Server.
Note that one section of the subscriptions docs around setting context is currently buggy and will be fixed soon: Fix subscriptions docs around context · Issue #5472 · apollographql/apollo-server · GitHub
A lot of people have put in substantial amounts of time to learn pubsub, channels, asyncIterator, etc. and to get them all working. My build tool is Meteor and I use swydo:ddp-apollo for Apollo setup. Hopefully it will be updated to work with Apollo 3. In the meantime this feels like a bit of an unnecessary rug-pull. 
@vikr00001 Please read the migration guide and the stated motivation for the change again. The guide suggests how to re-enable the same behavior you had before with the same functionality.
There’s no need to panic. All of these primitives are the same and you can keep using them. Furthermore, it is unlikely that these will be foreign concepts in any future subscriptions implementation as these are concepts that are inherent to many event-based subscription models.
Are you even using Apollo Server then? Are you using Federation or Apollo Gateway?
Looking at the code for swydo:ddp-apollo, I don’t see it using Apollo Server so I don’t know what you’d even need to update. In fact, based on a quick glance, since you only pass it the schema (optionally, gateway) and it creates the subscription server itself and binds it to Meteor’s connect app – I don’t even think anything would change.
If there are changes to make to the Meteor package are conceivably nearly as simple as the migration guide above suggests. Engaging with the package maintainers (as you’ve done in this issue) is the right first step.
Rather than merely being concerned please see if it works. If you encounter problems, bring concrete problems back and we’ll see if we can address them. You should start by determining whether you actually have anything to upgrade at all (e.g., does your project use the apollo-server or apollo-server-* npm modules?)
We know a lot of users have invested in GraphQL Subscriptions. We have also received plenty of feedback that suggests that the current subscriptions model can be improved and that users would like more flexibility. We want to improve on that in an incremental way that doesn’t require much more substantial interruptions, and this ask in the migration guide is meant to enable that.
Thanks!
Why aren’t we taking the time to forget about subscriptions-transport-ws and instead set up helpful guides for integrating with graphql-ws, which is actively maintained. The graphql-ws repo even has recipes to integrate with Apollo, I’m sure they’d be willing to coordinate / help out with getting their library setup portions as part of the official Apollo 3 migration docs.
Sounds like a better holdover bandaid than having the old obsolete library glued in again.
We are certainly aware of the more actively maintained graphql-ws and thankful for its existence and the hard work of its maintainer! In fact, we talk about this specifically in the migration guide, where we say:
Note that the subscriptions-transport-ws library is not actively maintained. An alternative, actively-maintained graphql-ws package exists, which we intend to support in a future release. These libraries implement different protocols for GraphQL subscriptions over WebSocket, so you need to adjust your client to support graphql-ws. At the time of release of Apollo Server 3, the graphql-ws protocol is not yet supported by GraphQL Playground or the Apollo Studio Explorer.
We go on to talk about this in our Subscriptions article, too. We believe that the missing support for the new graphql-ws protocol in GraphQL Playground and Studio Explorer is a non-starter for many users who rely on that functionality, and it creates learning and education obstacles for tutorials and guides as well. We understand that it is important to support that, but doing so while remaining compatible as a client will take work. (Also worth noting that clients need to be updated). None of this was believed to be worth blocking the release of Apollo Server 3.0.
To be clear, the subscriptions-transport-ws package is not still “glued in” and part of the motivation for removing it from Apollo Server 3 is because we know there are superior options, like graphql-ws and others. We’ve offered the migration guide with the lowest barrier to upgrading which lets users keep using it on its own and maintain compatibility. There are plenty of other reasons to upgrade to Apollo Server 3 aside from Subscriptions.
As for how to use graphql-ws: The README for graphql-ws (which again, is indeed a more actively maintained option) documents very clearly how to use it with Apollo Server in their Recipes section. It’s a great implementation and we do recommend giving it a try so long as you’re comfortable with any compatibility concerns!
Thanks very much for this. Yes, the first thing I did after upgrading to Apollo 3 was to test subscriptions. None of my subscriptions work at this time. Calling pubsub.publish() no longer results in a call to my subscription filter function. E.g. calling this in a mutation resolver:
pubsub.publish(IM_ADDED_CHANNEL, {
InstantMessage_Subscription
});
…no longer results in a call to this:
InstantMessage_Subscription: {
subscribe: withFilter(
() => {
console.log(`subscribed to InstantMessage_Subscription by ${Meteor.userId()}`);
return pubsub.asyncIterator(IM_ADDED_CHANNEL)
},
(objectToPublish, args, context) => {
debugger; <== NEVER ACTIVATES
[.....]
)
}
,
Checking via meteor npm ls, I do see apollo-server-core installed, but it’s not listed as a dependency of anything, and I’m not importing it anywhere in my app. So… that’s good in this case. How can I get subscriptions working again?
@TimFL (and just to be explicit, 100% agree with @abernix re graphql-ws. It was pretty disappointing to realize that the lack of “client” support for the new (presumably improved!) graphql-ws protocol meant that documenting it wasn’t the best choice for 3.0.0, but there’s a very good chance that the “full Apollo platform support for subscriptions” will be based on the graphql-ws protocol and implementation, which would include making it work with Explorer, etc.)
SOLVED!
It had nothing to do with Apollo 3 at all. Somehow upgrading from Meteor 2.2 to Meteor 2.3 is impacting pubsub.
I didn’t expect it given the Apollo 3 upgrade notes about potential impacts to subscriptions.
Thanks to all on this thread, and particularly @abernix for your thoughts!
Possibly it had something to with the node upgrade in Meteor 2.3. The code I was using to set up pubsub:
import {PostgresPubSub} from 'graphql-postgres-subscriptions';
const pubsub = new PostgresPubSub({
user: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbuser,
host: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].host,
database: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbname,
password: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbpsd,
port: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].port,
});
…stopped working for some reason. I updated to:
import {PostgresPubSub} from 'graphql-postgres-subscriptions';
import { Client } from "pg"
const client = new Client({
user: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbuser,
host: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].host,
database: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbname,
password: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].dbpsd,
port: Meteor.settings.postgres[Meteor.isDevelopment ? 'development' : 'production'].port,
})
client.connect();
const pubsub = new PostgresPubSub({ client });
…and, pubsub is working again.
That’s good to hear. We are currently evaluating the upgrade to Apollo Server 3 (we already run the “express flavor” with graphql-upload already being decoupled as outlined in the migration guide, so should be straight forward) but are hesitant due to the subscription woes. We’ve been using the s-t-ws package / default installation for subscriptions support and heavily rely on subscriptions still working after the upgrade. We’d love to go with something more actively maintained like graphql-ws, but also want to stay true to the “Apollo experience” because it makes upgrading easier when you go with “official” implementations.
Is there any ETA on when we can expect a big push for subscriptions for Apollo 3 or are we better of rolling the graphql-ws implementation on our own (or stick with s-t-ws migration guide variant for the time being)?
I’m so glad you got this sorted out! Thank you for circling back with your solution!
Our current thought is that we are going to focus on a solid @defer/@stream implementation first, then move on to subscriptions.
I’m going to close this since the original question was resolved and turned out not to be related to Apollo Server 3. Thanks again for working through debugging this, @vikr00001!