Light Service VS wisper

check out the `light-service` gem - it lets you create services that use this pattern and compose them into complex flows: https://github.com/adomokos/light-service

Similar to the above recommendations of Railway Orientated Programming and the Interactor gem, I use the Light Service gem. While it can sometimes be a bit verbose it excels in code reuse, testability, and composition.

View on GitHub

LightService

You can implement the service pattern as a PORO, but it helps to use one of the gems available to aid in code structure, orchestration, and error handling. The LightService gem provides a nice implementation without adding hardly any overhead. It’s design is very simple, as shown in the diagram below. An organizer is used to define the sequential workflow, which is made up of one or more actions. An error in any of the actions will short-circuit the entire workflow.

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.