Replacement for DDP?

I really love the reactivity DDP provides, and our app profits heavily from it. However, as soon as you go beyond the traditional web-browser, things get pretty muddy.

I had to implement my own DDP protocol for Unity / C#, and am now implementing one for visionOS / Swift. The main reason is that the existing implementations were so buggy that UX suffered a lot. Which is not the fault of the original library maintainers, it just takes quite some understanding how Meteor works to get it right. And I’m not even sure if my implementations are much better.

So I am wondering if there is any alternative to DDP out there, that is more based on standards, e.g. GraphQL or Apollo? The last time I researched on this, there was no proper reactivity support. And most people said: hey, just don’t use reactivity. But we need it :slight_smile:

As an alternative, I would really appreciate if Tiny would invest a bit in developing propert DDP protocol implementations for mobile devices. In the early days, there was one from the guy supporting Meteor Cordova, but its development stopped when he left the company. I think Meteor’s reach could benefit from these official ports.

1 Like

DDP uses websockets. Webtransport is the next evolution of tech for multiplex client-server real-time connection.

Pubnub can be a service that you need

I know. But I not only need the underlying protocol, I also need the features that come along with it, like methods and reactive subscriptions.

Pubnub seems to be a commercial product.

Maybe that profit can go to creating that non-web-browser implementation :wink:

I didn’t mean monetary profit. And yes, we’re doing this right now. But it doesn’t feel nice to re-invent the wheel all the time.

1 Like

Is your C# implementation open source and available anywhere?

You can get reactivity with ApolloGraphQL. The client subscribes to specified change “channels”. When a GraphQL resolver mutates a table, it publishes the change to that channel. Any clients subscribed to that channel get a notification pushed to them via a subscription resolver that uses an asyncIterator function to iterate over the clients who are subscribed. Apollo caches the results on the client and provides lots of cool ways of interacting with the server. My app uses a lot of reactivity.

It’s basically a fork of this repository:

I patched it quite a bit to work-around some bugs. My fork is in a private repo on gitlab, however. I could move it back to github, though.

1 Like

Sounds good. Are there any tutorials about how to set this up, maybe even for Meteor? Last time I tried it, there was literally no reactivity support whatsoever, so I gave up on Apollo.

This one looks good:

Tutorial: GraphQL Subscriptions on the Server | Apollo GraphQL Blog

I’m using this pubsub:

 import {PubSub} from 'graphql-subscriptions';
1 Like

Could you maybe share the codebase with me or put it up on github? I’m looking for a way to implement DDP using C# and stuggling with the old repo.

Would reactivity work then, if the table is mutated by something else other than a GraphQL resolver? MongoDB sends events through change streams / Oplog irrespective of whether it is Meteor modifying it or not.

This question is essential with more complex setups, where the database(s) entities may be mutated by multiple independent services.

Great question. GraphQL won’t know about anything unless it happens in a GraphQL resolver. My web app uses PostGres for everything except Meteor accounts. Meteor handles reactivity for accounts of course. But that may not work for the use cases that @waldgeist describes.

Some databases have triggers – I wonder if they could be configured to fire on table mutation, and call a GraphQL resolver?

Well, it kind of did. Indirectly. And only partially.
(Sorry for being so enigmatic, but we’re cooking something great and we don’t want to tell everything just yet.)

I’m working on some project for Meteor Software now and it required a (partial) DDP implementation as well. It’s not exactly like GitHub - green-coder/unity3d-ddp-client: Lightweight DDP client for Unity3D, GitHub - tanutapi/dart_meteor: A Meteor DDP library for Dart/Flutter developers., or GitHub - Gregivy/simpleddp: An easy to use DDP client library, but I believe it’d be enough to cover your needs.

It’s basically a “piece of code” that you can feed DDP messages. It’ll do the bookkeeping of the local database, i.e., the entire merge box implementation. It does not handle sending anything, though that’s easier and could be added later, to make it a proper DDP implementation.

It’s also important that it does not handle communication, so setting up the WebSocket is up to you. But as soon as you receive a message, just push it, and the local database will be updated.

Now, it may sound like a weird library, but here’s the thing: it’s written in Rust and, as such, could be compiled to WASM and used everywhere. We didn’t plan to open source it, but this thread suggests that there may be a benefit to doing so.

Do you think it would be helpful to you?


We use a similar approach, whereby MongoDB holds most metadata for what we keep in Postgres - because of the natively reactive Meteor + MongoDB combo. There are services mutating Postgres and then updating MongoDB independently of Meteor, but the Meteor app reacts thanks to watching the change streams, then doing other Meteor things as a consequence.

I have been working with PostgreSQL for best part of my career, even since before Meteor. In my opinion, if people thought Oplog is bad, wait until you get a flood of notifications from Postgres triggers. You may instead opt for LISTEN/NOTIFY, but that requires a direct connection, and when it comes to connections, Postgres may require a transaction aware pooler like pgBouncer to mitigate scaling challenges. But LISTEN/NOTIFY require session pooling, not transaction … so you are back to square one.

The bottom line is, without a database like MongoDB or RethinkDB which has native support for real-time change feeds, you would rely on constructs of various degrees of brittleness. GraphQL is great, but does not offer native reactivity in the way those two databases do. It does help to an extent, if you plan to only rely on GraphQL. Personally, I like my reactivity to be end-to-end, which means it needs to start as close to the database as possible.


A patched version version of that repo would come handy indeed, greatly appreciated if you could share it! :slight_smile:

In the IoT space, we are using quite a bit. They have clients for most languages/environments, including browser.

I use Apollo/GraphQL, it does support pub/sub and it works with Meteor. But Meteor’s pub/sub is the best.

I plan to do that. Unfortunately, the original repo already had some licensing issues, since the maintainer re-used an existing repo and put his own copyright notices everywhere. My version is also not really backwards compatible, since I changed some of the method signatures, partly because they had typos, partly because the way they worked did not match Meteor’s typical behavior and I wanted to mimic this a bit better. In its current state, the library is pretty tied to my needs and also integrated in my main app code, as this as easier to adapt. Thus, I’ll have to find some time to revert it into a pod.

1 Like

In its current state, the library became part of the codebase of my app. I could cut it out somehow, but it would not be a compatible fork anymore.