Future of Pub/Sub and DDP

We only looked at Meteor because it had pub/sub, i.e. realtime sync that allowed for very complex business logic. (Yep, it’s B2B.)

We liked Node because that reduced the number of languages, and Meteor checked that box.

We figured Mongo, or something similar, because we need a flexible record/doc structure for a few tables/collections — and Meteor checked that box.

We needed a build process, and Meteor checked that box as well. (And 1.3 has gone a long way toward cleaning up Meteor’s failings there.)

We needed users and some form of self-managed accounts, and Meteor helped out there too. (The profile subdoc is annoying, but livable.)

I could do without Blaze, or React for that matter (which I consider a step backward as it seems the JS alternative to feeding PHP to the browser). We were porting a large Knockout codeset and, for better or for worse, I find the Handlebars syntax bloated and I’m not a big fan of how it manages the DOM thru strings, so we only use it to bootstrap the page(s). At some point, we’ll factor it out.

Meteor has its warts and its weaknesses, but pub/sub and DDP certainly aren’t among them. I get that MDG is integrating Apollo in order to expand the architectures it can support, but I like how light DDP is and how I can write many of the business rules once, attach them to a transform (model) on the collection and use them on both server and client. I look forward to a long and healthy life for pub/sub and DDP :slight_smile:

8 Likes