DEV Community

Using Rails secret weapon: ActiveSupport::Notifications

Hugo Dias on July 03, 2018

Originally posted in my blog Ruby on Rails has a powerful weapon that not all developers knows about its existence. ActiveSupport Instrumentations...

Read full post

Timo Saloranta • Jul 4 '18

One gotcha: the current implementation is not asynchronous and all subscribers are updated sequentially. So if you want to do anything expensive inside subscribe hook, it's best to offload that part into a separate process by using queues (such as Sidekiq). That way the instrumentation won't slow down the customer phasing web process.

Pere Joan Martorell • May 28 '20

I don't understand why is synchronous, since it's an event that is listened by others I would expect it to be asynchronous. This has some implications, for example if I run an ActiveJob job and their events are listened by a subscriber and the subscriber raises an exception, this makes the job to fail.. I don't like it

Adam Cuppy • Jun 24 '20

The synchronous part is that the Notification event is run in sequence - just like a call to ActiveJob to enqueue a job would be an event in a sequence. However, unlike an ActiveJob enqueued job, where it's pushed to a datastore for another process to pick up and run, these Notification events are run fully at the time they're called.

As Timo mentioned, if you use that event to do some expensive processing, it would be in sequence and hold up the process until it was complete.

Hugo Dias • Jul 4 '18

Amazing tip @fonzai . Thanks for that!

Andy Zhao (he/him) • Jul 3 '18

Hmm interesting! I'm thinking of ActiveSupport::Notifications for a notification system, but I wonder if it would eat up a lot of memory. I've been back and forth between whether or not it makes more sense to use something like ActiveSupport or have a database table specifically for the notifications.

Is there a way to render the payload data in a view? I'm guessing you could do something like:

class NotificationsController
  def index
    @notifications = ActiveSupport::Notifications::Event.all
   # or whatever the syntax is
  end
end

Also I wonder if there's a way to expire events. Thanks for sharing this! Now my mind is brewing...

Andy Zhao (he/him) • Jul 3 '18

Ah, that makes sense. I don't have any solid ideas yet about a notification system, but I've always wanted to know what sort of implementation options there are. Definitely looking forward to the post! I'll message you on DEV Connect some time, too. :)

Cezar Halmagean • Aug 27 '19

One small thing to note:

You should follow Rails conventions when defining your own events. The format is: event.library. If your application is sending Tweets, you should create an event named tweet.twitter.

Charles Ellis • Jul 4 '18

I'm unclear on why the real world example provided is preferable to an implementation that calls MyMetricsService.send directly (or indirectly through dependency injection).

Could you elaborate?

Hugo Dias • Jul 4 '18 • Edited

Of course, Charles, and sorry if the example was confusing.

This API is a good use if you want to keep up with what is going on with your application under the hood.

Assuming that MyMetricsService.send is a service that sends a request to segment, now you need also to save this data to a log.

In this example you can add another line in that same event:

ActiveSupport::Notifications.subscribe /metrics/ do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  MyMetricsService.send(event.name, event.payload)
  MyLogger.save(event)
end

You can also subscribe to a specific type of events and handle differently.

ActiveSupport::Notifications.subscribe /metrics.purchase/ do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  NotifySales.call(event)
end

As you can see, you would need to change this in just one place.

The idea is basically to publish that something happened on the application and you can subscribe to this event.

Ricky Chilcott • Jul 4 '19

I've wondered the same thing as Andy. Did you ever write your post about a notifications system? I don't see it on your dev.to profile -- though I do see the one about Postgres Notifications.

I've been wondering if it would make sense to use the ActiveSupport::Notifications API to trigger events when certain objects have had a CRUD operation performed on them, and then have various subscribers trigger events such as ActionCable notifications, Emails to specific users, extended logging, storage of notification in a real notifications table, etc.

That way all logic associated with a specific event is in a single location as opposed to scattered all over.

Maybe it feels like too much indirection, and instead, you should just create a service class that triggers all of these operations after a successful change.

Thorsten Hirsch • Jul 21 '18

Very interesting. Until now I have always been using ActiveRecord callbacks like after_commit in order to trigger stuff. But the callbacks seem to be not 100% reliable recently on my production system and so far I couldn't figure out why.

Guess I'll migrate the callbacks to notifications, which seem to be more flexible anyway.