For a site that wants the "realtime" "reactivity" that Meteor provides on the frontend app, and have a job processing backend (something like Kue), clearly the frontend app benefits from Meteor. The backend processing does not need the reactivity of Meteor, except in realtime reporting in Admin UIs.
I do understand that Meteor is a full stack and handles both frontend and backend. When I state frontend in my question, its everything related to serving the UI for the users, so frontend app will include the clientside HTML/CSS/Javascript and the serverside node/database. By backend, I am referring to the data processing off a job queue like Kue/Gearman
Question: How would you structure such a site?
Meteor-backed server (or node instance) for the frontend, and an Express server with Kue/Redis on the backend? Or 2 seperate Meteor servers, one for the frontend one for the backend? Or 1 single Meteor server for both serving the frontend and doing the backend processing?
And what are your justifications for your recommendation? Thank you! :)
By backend, I am referring to the data processing off a job queue like Kue/Gearman
As this sounds like a rules/processing engine uncoupled from the "front end" that delivers both the "clientside HTML/CSS/Javascript" and the "serverside node/database" what I think may well serve your needs is a DDP client that can subscribe to the meteor server-side publications and queue up the jobs accordingly (using an engine such as Kue).
Such a client could live completely independent of the Meteor app in its own environment. This way, you can still leverage all the reactivity goodness you seek in Meteor, yet use more established processing tools for queue-based jobs that run independently of the UI. With the DDP client, you can also hook back into the UI to inform clients when jobs complete by leveraging the subscriptions.
Here is a node DDP client that may prove helpful. https://github.com/oortcloud/node-ddp-client
Hope this helps!