wisper VS Cells

Wisper: A Ruby gem providing a decoupled communication layer between different parts of an application​ -> I personally dislike wisper. I used it in the past and dislike the way of defining subscribers in a global way. I wanted topics to be arbitrary and each class to define what to subscribe for itself.

Wisper – the Publish-Subscribe design pattern

I haven't used it, but we're also considering it in our app for quite some time. Our main issue is mostly that our codebase is super coupled, especially some older code, and using events as a means of communication between different modules of the app can be nice way of decoupling things. I think this is the most common usecase, and for this you don't necessarily even need to persist the events, and also something like wisper might be useful https://github.com/krisleech/wisper.

Whisper (not updated since 2020)

I would use events. Every services broadcast its results and everything that needs to listen for them. It also great to decouple dependencies between services. I like the Wisper gem : https://github.com/krisleech/wisper

We follow the interactor pattern to store our business logic. So we mainly have skinny controllers, skinny models and then interactors. We also don't use ActiveRecord callbacks very much, we primarily use Wisper to broadcast events and then various domains can subscribe to the events they care about and respond accordingly.

It can be used with Ruby on Rails or other frameworks because I implemented with trailblazer/cells.

I agree, though cells does still have a larger following.

Better official documentation for cells: https://trailblazer.to/2.1/docs/cells.html

So what about the world outside Rails defaults? There are quite a few independent projects trying to help build components in the Rails view layer, among the more famous being Draper (utilizing the decorators pattern) or Cells (full-featured components in views). In the end, we decided to take a deeper look into a relatively new one – the ViewComponent framework.

GitHub has recently posted an article about view_component: https://github.blog/2020-12-15-encapsulating-ruby-on-rails-views/ Before it gets too popular I think I should share my experience with cells So that developers can have another chance to re-think and pick what to use for "encapsulated view components".

This, combined with the fact that we are using cells gem for some view components, resulted in another couple of hours of hunting for the problem (it takes some time to debug what exactly and how exactly changed in Rails internals) and then fixing this problem. At this moment, I already spent over 8 hours debugging Rails internals, different gem internals, fixing application, fixing tests, screaming internally.