Configurability of mail keys #9
Comments
You're absolutely right, the salt needs to be externally configurable. There are some other architectural changes which I've had in mind from using this system in production with tens of thousands of emails daily. I'm open to discuss these observations I have if you're open to implementing some of them. |
Ok, so what are your ideas? |
Here are some thoughts (sorry it turned a bit long): Slow queueingWhen you have a few tens of thousands of emails to send daily, enqueueing them for sending means taking these records from the list of subscribers and inserting corresponding rows in However, I don't see an easy way to avoid it except to use a totally different type of queue, which would probably mean a total redesign of this library. I am fine to live with the current situation, since If you have any ideas on how to speed that, though, I'd be open to discussion and implementations. Constantly growing finished_mails tableAfter sending, each email goes into the It also did contain the full interpolated unique body text, but at one point I added an option to not store these texts as the table quickly grew pretty huge. This is not enough, though, and I'd like the option to not save any records in the I think it is possible by:
Not storing finished mails in the DB will mean no constantly and quickly growing tables even if one sends lots of emails daily. This is my top priority. Other notesThere are some other options which could also be made configurable (e.g. Lots of the code can be refactored, simplified and generally improved. I'm also open to PRs related to that if you feel in the mood for it :) |
I share some of your observations. I'll be recolecting new observations and creating issues about them. |
Currently the
Smailer::Modesl::MailKey.generate
method is using MD5 with a fixed string and the email as salt.I think that at least the string should be configurable. What about reading that string from the configuration?
I also think that it could admit a block, so it's much more customizable.
What do you think? I would be pleased to implement it.
The text was updated successfully, but these errors were encountered: