At the end of the day concerns are just Ruby modules and they are a core feature of the language. They are an acceptable style of programming. It all depends on the task, your team's size/maturity and the hard boundaries you'd like to enforce.<p>The problem with concerns is that they can easily start leaking logic into other concerns or models and you've only got your team's conventions and common sense (which are all very soft boundaries) to steer you away from this. As a matter of fact, same goes for Rails engines - they make it very easy to call the parent app from within an engine and it's very tempting to do so at the cost of leaking logic and breaking these boundaries.<p>If your team can agree and stick to a set of conventions in regards to concerns, there's nothing wrong with using concerns the way Basecamp uses them. If you prefer stricter boundaries, there are other patterns that you can follow (like service objects or ActiveJob or events).<p>I personally use concerns when the behaviour tends to be very generic ("Paginates", "Cacheable", "SoftDeletes") and service objects for anything that touches the business logic.
I've been doing Rails development for a decade. Concerns are probably the biggest code smell/anti-pattern I've ever seen in any application. It's used as a bandaid to "break up" classes which do too much (but you really don't, you're just hiding the complexity), or it's way over done and everything is magic and almost incomprehensible and unmaintainable. Overall, just a total nightmare to deal with. Would not recommend, and I always try to steer people away from using concers during code reviews.
Forgive the slight tangent but I'd like to talk about Rails in general:<p>Just last night I was migrating an app from Rails 4 to 6.1 - I have been using rails since 0.9, but I think my long relationship is coming to an end.<p>What I loved about Rails was that it built a web framework with the same basic idea as Ruby: optimize for developer happiness. Trying to use the webpack integration (released with Rails 5.1 I think) is a nightmare. Suddenly my clean Ruby world is polluted by JavaScript package hell, there are now two parallel asset pipelines with subtly different behavior, I can no longer reference JavaScript directly in my views, and the convention over configuration Rails approach seems to have been superseded by a tool with the most nightmarish proliferation of necessary configs that I've ever seen.<p>To top this all off, none of this is documented well in any of the official Rails resources. The Rails JavaScript guide mostly focuses on their rails-UJS tool (which is fine, though also lacking in actual API documentation) and makes no mention of any of the webpacker stuff. The only docs I could find were in half finished pull requests in forked repositories, and some brief notes in markdown files.<p>Before starting with Rails 6, I was excited to try out the new Stimulus.js, and hopefully the improvements derived from Hey.com. Now I want to tear out every bit of JavaScript integration from the framework and manage those assets entirely on my own.
Concerns are the best example of the flaws in Rails and Ruby. The fact that DHH came up with a mixin applied at runtime as the solution to organizing Rails apps is frustrating. Other programming ecosystems have rightly moved away from mixins and do-everything-dynamically, along with moving away from mixing data and methods that self-mutate that data.<p>Having worked on large real world Rails apps, concerns are indeed a poor pattern in practice. They introduce hidden, untraceable dependencies, can clobber each other silently, make it difficult or impossible to understand where methods come from, and bloat classes into super coordinators, when "models" should only be data. Combine that with Ruby's horrible preference for metaprogramming and you get unmanageable code.<p>PS: If you work at a company as big as Github that can afford to literally employ Ruby core maintainers, then you are welcome to reply with "but it works for Github!"
I tend to only use concerns in extremely cut-and-dry cases. And even then, I sometimes get annoyed with them when hunting for that one method which is tucked away in a concern somewhere. But sometimes they are the best solution for making sure a bit of shared behavior doesn't get out of sync between models.
I'm an old dog. If I'm honest, Rails is the only thing I know (... I <i>barely</i> know a lot of things).<p>Counter do DHH's and core Rails' pattern, I'm thin models and Service Objects (<i>GASP</i> the horror!) to handle business logic. Models become DAO-y.<p>I had a lot of mental trouble handling different use cases for the same object. Like if an Admin vs User updates a post. The notification chains are completely different. So now my service objects look like: Post::UpdateByAdmin < Post::Base vs Post::UpdateByUser < Post::Base.<p>So, in general, my concerns are pretty thin. Like the post only handle data grabs. Even then, I'm guilty of doing what the post says from time to time especially when I couldn't see far enough into the future.
I've never really had to program using Ruby but just reading this Concerns concept makes me shudder. Am glad that I do not have to deal with the code structured in such way.