NYCPHP Meetup

[Matt Juszczak]

Hi John,

> 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 
website, etc.

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 
things.

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!

-Matt