[nycphp-talk] email system for website
matt at atopia.net
Mon Jan 4 14:32:50 EST 2010
> It really sounds like you really have your mind set on building a
> fancy pants queue system, but cant really justify it. Frankly, I
> think you are doing some technical masturbation, want to build
> something far more complicated than is actually needed, and want to
> solve problems that don't really exist. At first, you described your
> problem as having dual codebases, and then it morphed into a
> performance discussion. Which is it?
Thanks for your reply. Actually, it's the exact opposite. I want to make
the system as simple and easy as possible. The problem is that right now,
we have our front end code send emails. The developers are starting to
get annoyed at writing all of the logic over and over again for each front
end (for instance, we're in the middle of writing an iphone app as well,
which is a more simpler implementation, but we need some sort of REST
layer to facilitate communication with the database). I've been
implementing stored procedures and triggers into our database, which
removes much of the logic from the developers hands. Creating an account
is done the same way, whether you're using our mobile front end, primary
The issue we're having is with emails. If all emails were bulk, I'd
simply have a cron that ran, processed emails for subscriptions and such,
and send them. But, as we've said in this thread, some emails need to be
instantaneous. So drawing the line between what is done in the front end
code vs. what is done in background processing is what I'm trying to
decide. I'm using the terms "active" and "passive" to mean two different
The "fancy" queue you speak of is actually my favorite idea right now, as
it allows me to generate emails in a number of ways (triggers, stored
procedure, a manual INSERT into the table if needed, etc.). If the
developers need to do a forgot password email, they can call the forgot
password stored procedure, with the user ID, which will generate a hash,
generate an email in the queue, send the email, etc. Or, for more batched
emails, I have a trigger setup that creates an email in the queue
everytime a post or reply is made. The email queue won't be "one row per
email" - it will more be "one row per task". The background script will
know what to generate based on what's in the queue.
I'm really not doing any "technical masturbation" or any of the sort.
Promise. I'm just trying to make the system as flexible as possible. I
really don't think it's that complicated.
Thanks for your input!
More information about the talk