1

I've got a mean.js app I'm writing and I am conceptually confused about background processes.

I need to have some processes that run continuously in the background that operate on the mongodb database and do stuff like cleanup, email, tweets, etc.

I need a lot of the same functionality and libraries I have in my web app available to these background procs.

What is the best way to do this? Do I start with a brand new source base and treat these worker procs like a separate app? Or do I create, say, a daemon folder and fork the background procs when I start the server.js with grunt?

I think I am confusing myself and probably making this more complicated than it should be. I have looked at node daemon and child_processes and simple_daemon. But I'm not sure what path to take.

Thanks for your help.

An Old Guy and His Dog
  • 499
  • 1
  • 6
  • 17
  • 2
    once i got pm2 up, especially `pm2 save`, i stopped worrying about it. it's most maintainable (imho) to use multiple copies of more-or-less the same app, some doing just bg stuff, some answering the phone. if you really need the ram, you can comment out parts of the background worker that you don't need, or you can even conditionally require them to make the same file wear many hats. – dandavis Apr 28 '15 at 21:47

1 Answers1

3

You can use setInterval() to run scheduled or repeating tasks within the mean.js app. Because of the way node.js works, as long as node is running your app, any callback defined to run in setInterval() or setTimeout() will run once loaded. This means you can keep your background logic inside your controllers/models or in an adjacent file. You can include your background script, e.g. require()-ing it from the main app.js file, or from anywhere within your controllers, models, etc.

e.g.

app.js:

require('tasks/doStuff');
require('express');

/* express/app stuff here */

tasks/doStuff.js:

require('mongoose');
require('some/other/stuff');

setInterval( function() {
    console.log('interval happened');
}, 1000);

This approach does require some design/architectural considerations. Namely, your tasks are now tied to the successful execution of your node mean.js app. If your mean.js app crashes/dies, your tasks will have also died.

Marco Lüthy
  • 1,279
  • 1
  • 11
  • 21
  • Ahh. Ok, this makes sense to me. But here is my confusion about that: If the node.js app is a single threaded process, and if my setinterval thingy takes a long time (say a long query) wont that block incoming web requests? – An Old Guy and His Dog Apr 28 '15 at 22:07
  • 1
    Theoretically yes. But in practice, no. As long as you're using asynchronous methods on long-running functions, you won't block the thread. This is fundamental to Node.js. Here's more on that: http://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js – Marco Lüthy Apr 28 '15 at 22:11
  • 2
    it depends on if the long-running happens in-thread or not; typically, long delays in node happen off-thread, like waiting for http or a DB call. if youre grinding a big loop of data in JS, then yes, a long-runner will stall, but that's rarely the case, and if it was, you can move that slow js to another node instance(s), to keep your important thread from backing up. – dandavis Apr 28 '15 at 22:23