This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Hey <@U783MOJYF8Z> is the usage of ActiveSupport::Notifications still something you’d recommend for pub/sub (it was mentioned here https://shopify.engineering/shopify-monolith) ? Because the other day while at RailsConf I mentioned this to John Hawthorn and he was a bit worried we were using AS::N, I don’t recall exactly why he was worried though.
@santib Philip is on vacation! I can’t answer for him or shopify, but at Gusto we rolled our own pub sub using sidekiq because our understanding was that ActiveSupport::Notifications only permits synchronous events, which for a lot of folks misses one the biggest advantages of pub sub.
Good to know Alex. thanks. My understanding from this doc https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html#module-ActiveSupport::Notifications-label-Default+Queue is that by default it is synchronous with the usage of ActiveSupport::Notifications::Fanout but that you can change Fanout for a custom implementation.
At first I thought starting with a sync mechanism and then moving to an async mechanism was going to be the easiest way. In retrospect, I would go directly with async even if that means more work during refactoring of existing code.
That said, I think John concern with AS::N for pub/sub was not related to sync/async but something else… 
Message originally sent by slack user U783MOJYF8Z
I’m back from vacation! :male_fairy:
AS::N still seems like a perfectly good option if you want synchronous pubsub. Note that while async is more loosely coupled, sync does have the advantage of making tracing, debugging and testing much easier, and crucially if you introduce it in a refactor it doesn’t have to change runtime behavior of the code at all.
For async, we haven’t arrived at a convention that I can recommend, yet. IMO you probably want a transactional outbox in that case, and not some kind of “best effort” thing like the usual background job frameworks are doing.
Hey I clarified this with John. He says that it’s not that there is a technical issue with AS::N but that AS::N is built around timing and instrumentation more than for generic pub/sub usage, so that it doesn’t feel like the right tool to him. But yeah it’s a personal opinion, it’s fine to use AS::N 
Message originally sent by slack user U70TIGAX94P
Interesting, I remember talking to Rafael Franca about this and he didn’t seem opposed to the idea.
Super interesting thread as I’m looking into setting up something like this.
My thought was to have a wrapper interface on top of AS::N that allows consumers to decide if they’d like to consume a notification synchronously or asynchronously. Has anyone attempted something like this before?
@AlexEvanczuk your custom pub/sub around Sidekiq sounds interesting, any plan on making an open source version on rubyatscale 
?
Oh, and I had a look at wisper and I was also wondering if anyone is using it already 
We don’t have any plans to do that currently, but it’s an interesting idea! cc @stephan