Rails-way to implement site-wide notifications - ruby-on-rails

Question

I'm not new to MVC but I'm new to Rails, and I'm struggling trying to make everything "the Rails way". I want to implement site-wide notifications, so I've created a Notification model and created the many-to-many relationship between User and Notification.
The problem I face is when creating notifications, I have several entities which generate notifications in my code. You might get a notification when someone replies to a forum post you follow, you get a new private message, someone follows you, favs one of your entries, etc. I don't really know how to create new notifications.
Creating them in the controller feels bad, it can result in fat controllers very easily. I know about Service Objects and I love them, but I'm unsure if I should use them in this situation. I could have, for example, a notifications service which takes care of all notifications.
Another thing I thought is making all models which can generate notifications a "to_notification" method which returns the message the notification has, for example, the PrivateMessage model would have a method to_notification which returns You've got a new private message from #{username}.
The third solution I considered is adding a notify_user(user, message) method in the Notification model. But I guess the Controller still has to manage quite a lot of logic, like the notification message itself.
What is the most Rail-ish way to solve this?
Edit: I'm aware of Mailboxer but I'd rather do it myself.
Update
Okay so I ended up using a service object. Here's the Notification model
class Notification < ActiveRecord::Base
validates :message, presence: true
belongs_to :user
end
Pretty simple, then I created an action called NotifyUser in app/actions/notify_user.rb which takes cares of sending notifications
class NotifyUser
def initialize(user, message)
#user = user
#message = message
end
def notify
Notification.create(user: #user, message: #message)
end
end
Finally to send a notification I just call the action's notify method by doing NotifyUser.new(user, message).notify.
The logic for the notification message is handled directly in the controller or action. For example:
def follow(user)
success = current_user.follow user
message = "You've got a new follower, #{view_context.link_to(current_user.username, current_user)}!"
NotifyUser.new(user, message).notify if success
end
I still can't think of a more elegant way to create the messages. I guess this works good enough for me.

Answer 1

I prefer service objects for a non-trivial app. Here are my personal opinions.
Suppose you have a typical use case where a user sends a message to another user, e.g. Alice sends a notification "Hello" to Bob.
Here's an example of creating them in the controller that is "the Rails way".
Alice visits a page such as "www.example.com/notifications/", writes her message, taps the "Send" button.
Rails uses NotificationsController to create a new Notification model instance, i.e. record in the database.
When Bob signs in, the app queries the notifications to see if any are for Bob.
Here's an example of creating them using a service object:
You have a file such as "./app/services/notifier.rb" that exposes a plain old Ruby object such as "Notifier".
The Notifier object has a "send" method (or whatever methods you want).
The method takes care of creating a new Notification.
Here is an example of a hybrid:
E.g. a typical NotificationsController has some extra code: a non-user-visible class-level method, such as "def self.send".
The controller does double-duty as a typical REST resource CRUD manager, and also as a service object with an internal-facing API method.
My personal experience with this kind of hybrid is it works and it's easy for quick apps because everything's in one place, yet in a real app the hybrid tends to grows into a big ball of code that is hard to test with clean separation, mocks, and stubs.
To show the notifications to the user, and let a user interact with a notification (e.g. edit, delete), I do recommend a typical Rails controller, because notifications are essentially resources.
Another thing I thought is making all models which can generate notifications a "to_notification" method
Don't do this if you're building a real app. I've had to clean up many apps like this. Also it gets hairy when internationalization and localization are involved.
The only solution I've seen succeed this way is DCI, which can add a to_notifciation method at the point in time you need it. It's a great way to do it, except that DCI tends to run slowly in Ruby.
I considered adding a notify_user(user, message) method in the Notification model.
This is essentially making a class that is a hybrid: it does double-duty as your resource and as your service object.
It's fine, but it's harder to reason about because it's mixing model-related concepts (e.g. business logic, record persistence, etc.) with controller-related concepts (e.g. creating new resources).
As above, it's fine for a quick app, yet tends to grow into a big ball of code that's hard to test cleanly.