CODEWITHSUNDEEP
ruby-on-railsrubyruby-on-rails-3email
nightf0x
nightf0x

Reputation: 2041

Sending automated mails

I am currently working on a project based on ruby on rails. A particular feature of the website involves sending timely notifications through mails which contained a summary all the posts posted on the website. The mail was sent at a default interval of 30 days. So each user received a mail on a different day based on the day of his registration and also the date of the last news letter sent which was one of the data associated with the user.

But now I am thinking of adding settings to newsletter so that a user can configure the interval on which he wants to get the newsletter. So instead of sending newsletter based on the date last news letter was sent, I would like to send the newsletter to all the users on particular days of the month.

For example if a user wished to receive a newsletter weekly it would be sent on every sunday of the week. for monthly the newsletter would be sent on 1st on every month and so on.

One approach that came to my mind is to create a base class for sending newsletters and then creating subclasses for monthly,weekly... and so on to utilize the object orientedness of ruby. But I am not sure if this is the best way to proceed with solving the problem.

I wanted to know if there are other ways this problem could be solved. I do not need a ruby on rails way of solving, anybody having experience with solving this problem in any other programming language may help.

Upvotes: 1

Views: 919

Answers (2)

Marlin Pierce
Marlin Pierce

Reputation: 10099

This is a design issue, and it may come down to whether it becomes more cumbersome to break the scheduling behavior into multiple classes. You will avoid a case statement, which is an indication that polymorphism could have been used.

If you do, however, choose to use separate classes, this is a good time for the ActiveRecord implementation of the type field. Each subscriber belongs to a schedule. (I'd recommend a schedule has one subscriber.)

The schedules table would have a type field, with the name of the class. You don't have to set the type. Instead, to store the schedule, create the schedule object using the association from the subscriber object, and ActiveRecord will set the type field.

Now, whenever you get a schedule object from the database, it will be the class specified in the type field. You can have class for day of the week, a different one for date of the month, and as many different classes as different date calculation behaviors.

Do store the next due email date. This should be in the schedules table, but you could put it in the subscribers table, if that's more convenient.

Use a method to calculate the next due date. Make sure that method has the same signature in all the classes. So, for the monthly schedule, store the date of the month in the table and do not pass the date of the month to the common method. That way the delivery code can call the method to update the due date, without having to know anything about the schedule algorithm or data.

Upvotes: 1

Frederick Cheung
Frederick Cheung

Reputation: 84182

It doesn't feel like me that the monthly / daily/ weekly emails are different enough to merit different classes. Personally the way I would approach this would be to store the user's desired mailing frequency and then to store the user's next email date.

Finding out who needs an email today is just selecting users by next due email date (which will be fast if you index that column). When you send an email, update the column to be today + the appropriate offset. If the user changes there preference then recalculate their next email date. You could either do this by recording each time you've sent a user a newsletter (which might be interesting data for other reasons) or by maintaining a last email date as well as a next email date on the users table.

Upvotes: 1

Related Questions