wisper
packwerk
wisper | packwerk | |
---|---|---|
6 | 16 | |
3,233 | 1,505 | |
- | 2.4% | |
1.5 | 7.0 | |
2 months ago | 5 days ago | |
Ruby | Ruby | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wisper
-
Publish/Subscribe with Sidekiq
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.
-
OOP vs. services for organizing business logic: is there a third way?
Wisper – the Publish-Subscribe design pattern
-
Event Store with Rails
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.
-
Rails Google Cloud PubSub options
Whisper (not updated since 2020)
-
How to avoid if/else with different ramifications
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
-
"I'm the CTO of a Growing Rails Startup" Ask Me Anything
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.
packwerk
-
Must-have gems for mature Rails
gem "packwerk" - https://github.com/Shopify/packwerk | Allows modularising Ruby code, a must-have for growing projects.
-
Keep the Monolith, but Split the Workloads
Yep, that article is about very similar concepts but grounded in Spring as the framework.
I like what they do around package imports and it looks a lot like what we do at incident.io, with some rules about which packages can import what.
For people in the Ruby world who want a similar solution, Shopify provide an open-source framework called packwerk that is designed just for this:
https://github.com/Shopify/packwerk
-
All you need is Rails (Engines): Compartmentalising your Monolith
I’d probably go with packwerk before rails engines these days
-
How to break up a rails monolith
https://github.com/Shopify/packwerk allows you to make dependencies between components explicit
- Best way to go about fragmenting a Monolithic Rails application into Microservices.
-
OOP vs. services for organizing business logic: is there a third way?
Packwerk – to enforce boundaries and modularize Rails applications
-
Organizing Rails files by meaning
Take a look at Packwerk from some folks at Shopify - gets you the benefits of naming some components for organizing boundaries in your code, with each component having the usual rails folder structure, but without the hard isolation restrictions of doing so with Engines.
-
How to edit a model from another controller
Nothing is stopping you from doing so except you (and maybe packwerk, but you very likely don't have that installed).
-
The advent of tooling for Big Rails
For me, the most important aspect of a growing Rails app is handling of complexity and interdependencies and turns out Shopify's packwerk is just what the doctor ordered - it leverages zeitwerk loader to improve on Rails' vanilla file structure, allowing to group files by business concept or sub-domain and control visibility and ownership.
-
Exploring DryRB - Intuition of Results
Let's set the stage right quick. You happen to be in a large Rails application that follows along with something like Packwerk to clearly delineate different packages in your Rails monolith. Let's say you have 100 packs, which is not particularly unusual with larger applications.
What are some alternatives?
Rails Event Store - A Ruby implementation of an Event Store based on Active Record
Solidus - 🛒 Solidus, the open-source eCommerce framework for industry trailblazers.
Interactor - Interactor provides a common interface for performing complex user interactions.
appmap-ruby - AppMap client agent for Ruby
Rocketman - 🚀 Rocketman help build event-based/pub-sub code in Ruby
django-rq - A simple app that provides django integration for RQ (Redis Queue)
Cells - View components for Ruby and Rails.
whitehall - Publishes government content on GOV.UK
Light Service - Series of Actions with an emphasis on simplicity.
suture - 🏥 A Ruby gem that helps you refactor your legacy code
Waterfall - A slice of functional programming to chain ruby services and blocks, thus providing a new approach to flow control. Make them flow!
gitlab