Is this obsolete?

[mizzao]

meteor/meteor#4191 suggests that the easiest way to create a DDP client (collections and all) is to create a meteor app with the standard packages stripped out and just adding ddp-client, writing whatever the client is doing in the server/ code. Then, bundling this would create a DDP client application that could be run independently with Node.

Is this an accurate description, and if so, does that make this package obsolete?

[mizzao]

I just implemented this today: https://github.com/mizzao/cooperation-loadtest.

Works really great, and has client-side minimongo as well which would otherwise be really hard to pull off.

[vsivsi]

@mizzao That's pretty cool, thanks for sharing! I'm not sure that exactly makes this project "obsolete" though... Spinning up even a reduced meteor server is a pretty heavyweight thing compared to loading node.js and a couple of npm packages... If I'm not mistaken, the versions file in your project still shows a lot of meteor packages being pulled in to do some pretty basic things. Including loading and running a local mongoDB server (not minimongo) that you don't even use. I haven't tried it, but am I correct about that?

[mizzao]

Hey @vsivsi I didn't try that hard to optimize it, but I basically added meteor (after having removed meteor-platform) just to get Meteor.settings and Meteor.startup, neither of which were strictly necessary.

Theoretically speaking, the bare minimum packages required would be just ddp-client and minimongo. However I was also running PLUGINS-PREVIEW@2 which seemed to have a bug with only having ddp-client as a package, so the other packages were just a quick hack that seems to have fixed the dependency resolution.

It is true that I needed mongo for new Mongo.Collection, although I'm sure improved modularization by Meteor could eliminate the need to start up the unnecessary MongoDB instance. Moreover, the process appears not to be heavyweight at all; one Node process was sufficient to simulate 100 DDP clients and completely max out the Meteor process's CPU without going above 5% on my machine.

All in all, despite the additional machinery that Meteor uses run this, it still has the benefits such as hot code reload and minimongo queries that seem to be much improved over a low-level DDP client, and it's possible to get things working much more quickly.

[vsivsi]

Thanks for clarifying! Of course "heavyweight" is in the eye of the beholder. If I'm going to spin up 1000 AWS EC2 instances to act as compute workers for my job-collection, then it might cost some real money if the delta between running "node.js + ddp-client" vs. "slimmed Meteor server" requires a bump up in the capabilities of the instances to run.