I’m not familiar with how websockets work on Galaxy. DDP works for sure, so you’re safe there. Maybe someone with Galaxy + “normal” websockets knowledge can answer your question.
Another benefit of DDP is the possibility to add a rate limiter. This is great for DDOS protection or prevention users from overloading your server. I added some documentation about this in the README:
Thanks for making this happen @jamiter I find this a very interesting project.
In addition to providing a very smooth integration of Meteor DDP with GraphQL Apollo, I think this is also demonstrates of how flexible DDP is since it can be used to fully absorb GraphQL standards.
@jamiter Did you face any major challenges when working on this integration? did you need any create any workarounds when using DDP as a the transport protocol?
@diaconutheodor don’t you think that is kind like the other end of the spectrum when compared to your “Fusion” initiative by promoting web sockets/DDP all the way even for GraphQL queries and mutations?
Yes it is on the other spectrum, but I don’t have anything against Apollo. I just know that there are much better alternatives (good ol’ Meteor and Grapher)
Hi @alawi, great question!
For the query and mutation part it was very straight forward to use DDP. Because the difference between an HTTP call or a DDP method is very small. But DDP gives advantages like using Meteor accounts out-of-the-box and much more.
Side note: There wasn’t a default HTTP GraphQL setup for Meteor yet when I stated DDP-Apollo.
Subscriptions though were are different story. DDP is not as flexible as one might hope and subscriptions are very tight to Mongo collections. I first implemented it using a fake collection, but that would save every update as an entry in MiniMongo. I later changed that to manually listening to all DDP messages on the client and filter out the subscription messages. Not such a bad solution, but no standard DDP either. I’m thinking of maybe using the meteor ClientStream package in the future:
The name DDP-Apollo mostly comes from the first query only implementation, using a Meteor method. There was a time when subscriptions didn’t exist yet.
I think @alawi was more referring to DDP vs non-DDP than Apollo vs Meteor / Grapher.
I’m no expert on Grapher, but the powerful thing about Apollo is all the tooling, broad usage/adoption, technology independent, backed by big companies and of course all the conferences, meet-ups and just plain marketing.
Even if Grapher is the better tool for the job (and I’m leaving that in the middle deliberately) it’s hard to compete against the GraphQL/Apollo community.
The funny thing is: the same goes for this package. I’m helping Meteor developers to get to know GraphQL with a minimal effort or change in their setup. But DDP is very Meteor specific and the adoption rate outside Meteor close to none. So I totally get that people will choose the default HTTP approach, like all non-Meteor developers. But for people still in the “Classic” Meteor bubble, why not make it easy, the Meteor way.
I totally get why people like Apollo, and depending on the use-cases I see it as a better fit than Grapher, even if you are using Meteor. This is why this package is super nice and it’s the perfect integration and I thank you for that.
My main issue with Apollo is the fact that it breaks the core principles that made me love Meteor in the first place:
None of these are present in Apollo.
Regarding tooling and performance monitoring, Grapher queries are methods and publications, you can already measure performance inside the APM. No need to use Engine/Optics.
Grapher took inspiration from GraphQL and initially, believe it or not, it was using GraphQL! But in time I realized that I’m the JS world and this is crafted for Mongo and Meteor. By laser-focusing and depending on these technologies you create the perfect tool.
As a programmer that started coding at a very young age and was exposed to very complex problems and ways of doing things, I always come back to what’s simple. Apollo has a limit of simplicity it can reach because it’s a full data-layer that tries to make it work with any kind of database and make GQL available in any language.
That being said, I’m not against Apollo at all. It’s super good, and Facebook Engineers really solved the all-around data layer in a very elegant way, and again GraphQL was the source of inspiration for Grapher, without it, I wouldn’t have had the “a-ha” moment.
I decided to release the current version as 1.0! 
There were a couple of improvements made, mostly documentation, and the API is stable at the moment.
To try it out:
meteor add swydo:ddp-apollo@1.0.0
Run into any bugs? Please report those in the repo!
Is a call to pubsub.publish() required in every mutation in order for client to automatically see updated data?
Why is PubSub from graphql-subscriptions not recommended for production?
From the documentation:
Note that the default PubSub implementation is intended for demo purposes. It only works if you have a single instance of your server and doesn’t scale beyond a couple of connections. For production usage you’ll want to use one of the PubSub implementations backed by an external store. (e.g. Redis)
The default implementation is in memory. If a user connects to server A and you publish something on server B, the user won’t get notified because it has a websocket connection to server A. If you use something like Redis, the notification will be send to all servers.
And yes, you’ll have to call pubsub.publish() on every change you want to send to subscribers, like when you mutate something. The thing is, GraphQL subscriptions are mostly useful for events and are different than the live queries we are used to in Meteor (with meteor pub/sub). The good news is that @live queries will also come to GraphQL, preventing the need of so many manual publish calls. Read more about the current status here:
I recommend watching the mentioned video.
Thank you @jamiter for the explanation. I feel that options.refetchQueries in a mutation does the job of updating the client with less code, so I may not need to use subscriptions.
I like that we no longer need a separate server to use Apollo, which saves a lot of hassle. Beginners could skip Part 2 — The Server: setting up a simple GraphQL server in 5 steps entirely.
Just as an exercise using your package, I’ve been rewriting simple-todos-react to use Apollo (removing withTracker, publish and subscribes and Meteor.calls) and managed to get queries and mutations working.
Hey @alawi, because you were be interested in how this all got started I though you might like to see this:
The funny thing was that the idea got rejected because the implementation could become to much Meteor specific and fall behind on the default Apollo setup. The fun thing is that it’s ahead of it by supporting subscriptions out-of-the-box and works with most other middleware, because it’s just an Apollo Link.
I plan to keep it ahead of the game 
That’s great thanks for sharing @jamiter! I’m surprised the PR didn’t go through. I think a tech fall behind if the team behind it did, as long as the team is active, up to date and believing in their vision, the code will follow.
@tab00, although fetchQueries might update the app for the current user, I don’t think it will update the page for other users. That’s where subscriptions come into play. Right?
Yes, you are right, so it depends on the use case.
For data that needs to be pushed to many users, subscriptions would be required. The graphql-subscriptions documentation makes it seem that the default PubSub is even less scalable than Meteor’s subscriptions. Though it feels quite inconvenient to need to set up (and pay for) Redis / MQTT / Kafka etc.
So if we need subscriptions for a production app that uses Apollo, are there any other options?
Well, there is the option to use Mongo for it. You could create a collection where you publish changes to and listen to items getting added on all servers. This is possible, because Meteor is of course able to listen to collection changes. With the right indexes, old messages will automatically be cleaned up. Make this use the PubSubEngine interface, open source it and you’ve made the life of Meteor developers easy again.
We are so spoiled with Meteor, because everything is done for us 
Looks like some work on a Mongo GraphQL Subscription already started here:
Work on it stopped a year ago though, but it’s still interesting as a reference. I like the fact that it’s not Meteor specific, but directly uses the oplog. It doesn’t allow triggering a custom event though. Maybe I can mix it with I had in mind…
Cool, I had totally forgotten about that! But that was made in the early days of Apollo to get a feeling on how it compares against meteor. I haven’t followed Apollo / Graphql development since, so no idea if any of it is still relevant.