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?
4 Likes
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.
2 Likes
A patched version version of that repo would come handy indeed, greatly appreciated if you could share it! 
In the IoT space, we are using NATS.io 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.
That would be awesome, if you can find the time. Backwards compatibility is not issue for me at least.
Several years ago I created an experimental C# DDP package named DDPClient.NET, by porting the Java package delight-im/Android-DDP and using the third party C# library WebSocket4Net to provide the WebSocket layer.
I last worked on it in April 2018. I am happy to share the code in its last state if you want it, but I would not encourage its use for new projects.
C# and the .NET ecosystem have evolved a lot over the last few years. If I were writing a C# DDP implementation today, I would almost certainly reimplement it from scratch using the asynchronous programming model in .NET Core using the native WebSockets implementation or SignalR.
I actually think it would not be too difficult to write a modern implementation from scratch if you coded collaboratively with a good coding LLM like OpenAI GPT4 or Anthropic Claude 3 Opus. The DDP spec is a short document so an LLM can read it fully.
2 Likes
I wonder what would be needed, to switch to this from Swydo:ddp-apollo, since that seems to require fibers?
Sorry, my post was misleading. I thought the request was about my Swift impementation. It was actually about the C# fork, which I haven’t put up on Github yet. And it’s not for JavaScript either, so it would not be a replacement for Swydo:ddp-apollo. I deleted my post.
maximtimeclock@waldgeist ,
You’re right; while GraphQL and Apollo offer strong data fetching capabilities, they traditionally lacked built-in reactivity support. Consider using WebSockets for real-time communication between your server and mobile app. Libraries like Socket.IO.
While you mentioned concerns about existing DDP libraries for mobile, there might be improvements since your last exploration. Look into actively maintained libraries like meteor-cordova.
Evaluate how much effort it would take to migrate from DDP to a new technology compared to improving your current DDP implementations.
Consider your team’s experience and comfort level with different technologies like GraphQL, WebSockets, or Firebase.
And Real-time data needs and offline functionality are crucial factors when choosing a communication protocol.