# Half baked "backgrounder" idea

**URL:** <https://www.ruby-forum.com/t/half-baked-backgrounder-idea/151409>\
**Category:** Rails\
**Created:** [October 21, 2008, 4:20am UTC](https://www.ruby-forum.com/t/half-baked-backgrounder-idea/151409 "2008-10-21T04:20:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeffpritchard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@jeffpritchard](https://www.ruby-forum.com/u/jeffpritchard)\
**Post date:** [October 21, 2008, 4:20am UTC](https://www.ruby-forum.com/t/half-baked-backgrounder-idea/151409/1 "2008-10-21T04:20:26Z")

</div>

At present I’m working on a couple of different Rails projects, each of  
which has to have background tasks running for a variety of reasons  
(handling large imported files, sending reminder emails at predetermined  
times, handling incoming emails, etc.)

So far I’ve been using the “spawn” plugin for this in preference to the  
many other equally undocumented choices mostly because it was the first  
one I tried that just “worked”, and it is getting the job done well  
enough. Biggest problem is just remembering to restart the silly thing  
whenever the Rails app is restarted for a deployment or whatever.

Today while researching a new feature to add, I stumbled upon a  
different idea and I wanted to get some feedback from the community on  
the pro’s and cons of doing “background tasks” in this way:

Why not just write a second little Rails app that doesn’t happen to have  
any end-user facing UI? This app would use RESTful stuff for handling  
lengthy tasks such as handling large import files and such.

A third app would be a mindless loop, continually checking various  
things to see if it needs to do something like send a reminder email or  
handle incoming emails.

To be sure, this approach would suck up some RAM, but it would make  
splitting up the app when the user base gets huge an almost trivial  
proposition.

If one were to serve these three apps (the mail app plus two different  
types of background app) via “mod\_rails” (Phusion Passenger), would they  
effectively all be in separate threads and avoid holding each other up?

Are there any hidden gotcha’s involved with having three such apps  
connected to the same MySQL database?

P.S. I can’t exactly put into words why this method appeals to me over  
the current method of spawning a simple background process that is more  
closely coupled to the main Rails app. It just seems like an  
interesting way to do it. Wondered what others think of it.

thanks,  
jp

---

<div class="post-metadata">

**Author:** ![jeffpritchard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@jeffpritchard](https://www.ruby-forum.com/u/jeffpritchard)\
**Post date:** [October 21, 2008, 10:28am UTC](https://www.ruby-forum.com/t/half-baked-backgrounder-idea/151409/2 "2008-10-21T10:28:44Z")

</div>

Have a look at backgroundrb. [http://backgroundrb.rubyforge.org/](http://backgroundrb.rubyforge.org/)

On Oct 21, 7:20 am, Jeff P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)