Reply messages from server to Node app
Opened this issue · 3 comments
I have a feeling this might be a stupid question, but I figure it's better to ask than make a mess of things!
Because I have a DDP stream running from my Node app to a Meteor server somewhere in the cloud, is it possible to then send command back over that same link? I'm trying to achieve the ability to send configuration, etc to the Node app without the user needing to punch a hole in their firewall, etc. etc.
Alternatively I was looking into STUN/TURN/ICE but means I need to do a whole bunch of research into how to deploy such things.
You can do this... While it isn't symmetrical with calling a Meteor method, you can build a very effective back channel using the existing pub/sub capabilities.
Your Meteor server can "publish" a custom document set and your node.js client can subscribe to it and observe it for changes. If you want, the publish function can construct a specific document set for each authenticated user, or comnection, or IP address. It can publish only a single document to each node.js client, and then publish changes to it when necessary. On the client side. This will appear as calls to the onChange callback you define in the subscription observe.
It's powerful, and can be used to replicate pretty much any remote calling functionality you can imagine.
Is that a limit of the implementation that I can only subscribe to a single document from the Node side or just an example? This would work incredibly well for the configuration side.
For things where I want to trigger an action though, would I need something else or could it be done with pub/sub as well somehow? For example I currently have an API call of /setup/quickScan which returns a JSON result.
The node client will receive as many documents as the server publishes for that subscription. It's all up to you. Each document can be treated as an RPC invocation. If you need to "return" a value for that document, you can invoke a method on the server with the document _id and return value. The client knows that worked when the "calling" document is removed for the subscription...
Although... this whole architecture is starting to sound pretty familiar... It's already been done! You should check this out instead of rolling your own: https://github.com/vsivsi/meteor-job-collection
It works essentially as I describe above.