Now that Apollo Client 2.0 is released I decided to update the DDP-Apollo package to support it. We’re getting close to a stable API and 1.0.0 will be released soon.
Why choose DDP-Apollo?
DDP-Apollo has been created to leverage the power of DDP for GraphQL queries and subscriptions. For Meteor developers there is no real need for an HTTP server or extra websocket connection, because DDP offers all we need and has been well tested over time.
DDP-Apollo is one of the easiest ways to get GraphQL running for Meteor developers
Works with the Meteor accounts packages out of the box, giving a userId in your resolvers
Doesn’t require an HTTP server to be setup, like with express, koa or hapi
Supports GraphQL Subscriptions out-of-the-box
Doesn’t require an extra websocket for GraphQL Subscriptions, because DDP already has a websocket
Easy to combine with other Apollo Links
Already have a server setup? Use DDPSubscriptionLink stand-alone for just Subscriptions support
Works with Apollo Dev Tools, just like any other Apollo link
Installation and documentation
See all the details in the README of the repo:
Any downsides to this approach?
There are some points to take in consideration when choosing DDP as a network interface.
External consumers of your API
DDP-Apollo works great when only your own Meteor app uses your GraphQL API. And it also work for other Meteor apps who want to consume it, because they can simply make a DDP connection to your app. But if you have other apps or processes that only support HTTP then you still need to setup something like an express server. Luckily DDP-Apollo does nothing to your resolvers or schema, so you can reuse those for your HTTP setup and run both the DDP as the HTTP version side by side.
Apollo Engine
Apollo Engine is the successor of Apollo Optics. DDP-Apollo supports Optics out-of-the-box. Apollo Engine though works as a HTTP proxy, meaning it doesn’t support websockets (yet). This means no support for GraphQL subscriptions and no support for DDP-Apollo. If Engine is a requirement (and I must say it’s awesome), then DDP-Apollo isn’t for you.
Moving away from DDP
Like mentioned above, DDP-Apollo doesn’t modify your schema or resolvers in any way. If you ever wish to just use HTTP or move away from Meteor you can reuse your schema and resolvers without any changes.
I’m continuing my monologue here () by saying DDP-Apollo is front-end agnostic. You can use it with React, Angular, Vue or Blaze, because it’s “just” an Apollo Link.
The Apollo team really did a briljant job with how they created Apollo Links. You can combine HTTP with websockets or DDP or even local state if you like:
I took an already existing Meteor Apollo starter kit and modified it to use DDP-Apollo and added a subscription on the way. Mutations are very simple, but I could add those too. Check it out:
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)
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:
Very simple setup
Elegant & painless reactivity (and now extra scalable, I’ve been working with different companies, and redis-oplog simply rocked, can’t wait to post the case studies)
Elegant RPC (You cannot get more elegant than Meteor.call(‘functionName’, arguments) )
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.
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:
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.
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.
Luckily it’s very small.
) by saying DDP-Apollo is front-end agnostic. You can use it with React, Angular, Vue or Blaze, because it’s “just” an Apollo Link.