This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U70VHJW00FC
New here as well. I work with @thewoolleyman and <@U70QMTZKWY8> at GitLab (though we are on different teams.) My interest in Ruby is primarily around improving performance and memory use of Rails applications. Modularization has a significant impact on this since we run many different work loads at GitLab (scaled and configured differently) that are all instances of the same app, which means we do not utilize available resources as efficiently as could be. Breaking down the monolith may help us deploying smaller units into production that only load those parts of the code base that are actually required to service those work loads.
Hi <@U70VHJW00FC>, this sounds like really interesting stuff! One of our end goals is that the gradual adoption of packwerk + package protections in a package can allow it to be automatically built, tested, and deployed independently. Imagine if we have package protections such as “this system uses its own DB, “this system exposes a serializable API,” “this system declares its own gem dependencies,” and more. The idea being that we capture each requirement for a system to be built/tested/deployed independently as its own tool with the ability to be gradually adopted, thereby allowing us to systematically move towards those small units and most importantly allowing us to be able to determine separate-deployability at build time rather than as a conscious human decision.
Sounds great! Absolutely. Happy to share any progress we make over time, but I do suspect it will take a long time. We will likely start with something simple and boring, such as doing some house cleaning around directory structure and breaking up our proverbial kitchen sink lib/.
The interesting things will come later I suspect.
I think another challenge we face is that developers are looking at the problem through different lenses. There is the DDD and clean architecture lens, which has the primary goal of subdividing a large code base around domain specific concerns. There is an entirely different angle which focuses more on a technical split and tries to co-locate those parts of the code base that perform similar work loads. I am not sure what we will start with, but I assume the latter, because success is much easier to quantify too.
We definitely started with the former, focusing on domain driven concerns. Packwerk is really well optimized for this process. You can learn a bit more about the process here at Gusto in my RailsConf talk
New here as well. I work with @thewoolleyman and <@U70QMTZKWY8> at GitLab (though we are on different teams.) My interest in Ruby is primarily around improving performance and memory use of Rails applications. Modularization has a significant impact on this since we run many different work loads at GitLab (scaled and configured differently) that are all instances of the same app, which means we do not utilize available resources as efficiently as could be. Breaking down the monolith may help us deploying smaller units into production that only load those parts of the code base that are actually required to service those work loads.
