Listening on a socket from within Meteor server?

I have a standalone Node server that receives data via a network socket, aggregates some statistics, and writes them to Mongo.

A Meteor app that watches that Mongo instance and displays that data on a web page with all of the usual Meteor magic :smile:

It is a little clumsy to have to have these two standalone servers running to do this; it’s more of a maintenance burden and it makes it harder to have one simple script that starts them and stops them.

Is there any way to fold my standalone Node server into my Meteor app’s server process? From what I’ve read thus far, the answer seems to be “no” (“Meteor is single-threaded”, etc.), but I thought I’d ask in case anyone knows some tricks for making this kind of setup more cohesive.


We specifically split out features into micro services and use meteor much like you describe…as master of the mongo docs (view, edit, etc)

Thanks @jasoncchild, that’s good to know.

Related question: is there any way to communicate with my Meteor server from another process besides sending messages via Mongo?

sounds like you could just refactor your node process to speak DDP and would be golden :smiley:

Hm, that certainly sounds like an interesting idea, but I’m not fully seeing how that could work.
One approach would be to:

  1. change the external process “E” (that is sending data to my node server “N” today) to speak DDP to N instead,
  2. move N’s logic into a designated endpoint within my Meteor server M, and have E simply connect to M at that endpoint, and speak DDP with it.

However, E would be pushing data to M in this world, but M only has Meteor.publish methods, being a Meteor server process; I don’t see how I could “subscribe” in M to data in E. Do you know of example code demonstrating such a role reversal on the part of a Meteor server process?

A second approach would be if there was some way to open a second port in my Meteor server; is that possible?

Oh, I’d start by just taking your node proc that writes to Mongo and instead post messages via DDP to meteor…which can insert them into mongo since there currently exists some tight coupling between DDP and mongo/minimongo collections (super cool).

in this scenario your node proc is a bridge between the incoming websocket and meteor. from there you could explore refactoring the external proc that uses websockets to hit your node proc to instead just connect to meteor over websockets and speak DDP directly.

in the end it really depends on your use-case requirements

check out the spec doc, i found it to be most informative

Server side of Meteor IS a fancy Node.js app. It’s possible to easily embed almost any node application into Meteor. Simply Npm.require your app, and most of the time that’s all you have to do. Listening on a net socket is just like doing it with a plain Node.js app. Here’s a POC:

Now that’s out of the way, Node.js apps are single threaded (so is Meteor). It will not stop your app from working as expected but it can only use a single cpu core at a time to run Node.js code. If the aggregation part or some other part on the application requires too much cpu, response time of your Meteor app will increase. So, most of the time, writing Node.js apps which require more cpu is not a good idea.

1 Like