Now that my first Rails application is in production, there are many things I wish I would have know at the onset. Not the least of these is how slow (to send) and tedious (to implement) email messages are within the framework.  Firstly, the creation and maintenance of mailers is just tiresome. Having multiple views for each message; not to mention keeping the text up to date. Second, being new to pretty much all things web based, I initially inserted all of the sending of emails into the main request/response cycle of the controllers. Needless to say, once we began load testing we started to see terrible performance. A lot of timeouts, and ugly blank screens coming back. Upon investigation, we determined that the emails were the culprits. Being a functional requirement, and therefore unable to be done away with, what were we to do?

We decided to do the same thing you do with anything that is slow and bothersome: we made it someone else’s problem. To address the maintenance issue we created one mailer to rule them all, and pushed all aspects of all the messages into a database table. This, combined with a nice variable substitution object, allows the end users to maintain the emails their system is sending out. This simple move made everyone on both sides extremely happy (and happy customers make happy bosses).

Next, we farmed the sending of the messages off to a queue background job. Since we are using a Postgres database, we decided on the Que gem. The setup for this was super easy, and can even be configured to work with your testing framework so as not to invalidate that wonderful suite you have going. Implementation was straight forward and we instantly saw improved performance.

I plan to use this paradigm for every application I have in the future, and I hope this helps another new RoR developer avoid learning this lesson the hard way.