The goal of this discussion seems not to follow what the big are doing but more to relate to multiple facts:
Rails is not only used by smalls teams
Rails is also used for different types of projects (simple to complex)
Architecture modularity could help in all cases the same way that you can decide to use ActiveStorage or an other module of Rails. For those who could decide to manage their domains differently than by using controllers/modules or models/modules it could help a lot to solve the previously indicated issues that engines and gems can’t solve.
It could be a great idea to find a way that will allow complex teams or projects to succeed in what they’re trying to achieve without all the current pains.
When I said “the big players”, I just meant they’re usually forced to solve/address this problem, and they have the expertise and budget to develop something very robust. But from all the articles I’ve read about this - every “big player” implements something slightly different. One of the great things about Rails are conventions that result in developers being quickly onboarded to work on different projects. So I see an advantage to maybe having a consistent approach - even if “big players” have to alter it for their specific needs. Which Engines sort of are now … it just happens that they’re not really perfectly suited - out of the box - to this task.
I know most medium sized project benefit too - every project I’ve worked on in Rails would have benefited - I’d describe them as all medium sized. The idea is to present people with tools to easily identify modular/domain boundaries in their code base early, rather than later when it gets more complicated to pull the code apart.
Even the smallest of projects could benefit under the right circumstances. Something as simple as your admin UI vs front end could be better separated than with what engines or namespaces currently offer.
It looks like this discussion tapered off. This is a topic that is of particular interest to me. I’ve experienced many of the same pains when trying to use engines & gems in the past when my goal was to organize a growing project within the same repo (rather than spinning off packaging libraries like Devise).
On my latest new project, I’m very interested in following the advice offered in this popular post:
I think the first step is to create a starter repo that shows an example. I think the scope of this starter repo would be something like:
New rails app with no “/app” directory
A couple gems stubbed out with an example dependency and a couple example tests within each
A couple engines stubbed out with an example dependency between them and example tests
The bundles loading modifications mentioned in the article
The gemfile hack to enforce boundaries by only loading dependencies when running tests
Has anyone headed down this path? Anyone interested in helping? The closest I’ve found is this:
Maybe Dan Manges himself (the author of the original article) might even be willing to help.
