app\/packages<\/code> folder where we will place all our packages. In order to isolate our packages we have to separate every MVC concept<\/strong> in one folder. Taking the CodeTriage project<\/a><\/strong> as an example we will have something like the following picture.<\/p>\n\n\n\n![\"package](\"\/app\/uploads\/2024\/05\/2.png\" "\\"package")
<\/figure>\n\n\n\nIf we try to run the server, it will fail to find the constants. That’s why we need to add a line of configuration to our application.rb<\/code><\/p>\n\n\n\nconfig.paths.add 'app\/packages', glob: '*\/{*,*\/concerns}', eager_load:true<\/code><\/pre>\n\n\n\nNow the application works but it cannot find the views, so we need to add another line of configuration to our application_controller.rb<\/code><\/p>\n\n\n\nappend_view_path(Dir.glob(Rails<\/a>.root.join('app\/packages\/*\/views')))<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Create the packages<\/h3>\n\n\n\n
Our structure is ready, so now we can start creating the packages. In order to do that, we only need to add apackage.yml<\/code> to every folder with the following configuration:<\/p>\n\n\n\nenforce_privacy: false\nenforce_dependencies: true<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n![\"package.yml\"](\"\/app\/uploads\/2024\/05\/1.png\" "\\"package.yml")
<\/figure>\n\n\n\nenforce_privacy<\/code>gives us<\/a> the possibility to isolate all the constants of the package and work with a public API<\/a>. In order to expose the public constants, we need to add the constants in, for example packages\/users\/app\/public.<\/code>For now we are going to set this configuration to false<\/em>.<\/p>\n\n\n\nenforce_dependencies<\/code> will enforce the dependency of a package and check for all the constant references. If a dependency is not explicitly defined it will be a violation of the boundary.<\/p>\n\n\n\nValidating the package system<\/h3>\n\n\n\n
Packwerk<\/strong> established a criterion we need to follow in order to have a valid package system. We can start running packwerk validate<\/code> in our console.<\/p>\n\n\n\n This will check our folder structure, package configuration<\/strong>, and autoload path cache.<\/p>\n\n\n\nRight now, our application is not valid and we have to fix the load paths inpackwerk.yml<\/code>.<\/strong> In order to do this, we only have to add the missing paths.<\/p>\n\n\n\n# packwerk.yml\n\nload_paths:\n.\n.\n.\n\n# Users\n- app\/packages\/users\/controllers\n- app\/packages\/users\/models\n- app\/packages\/users\/package.yml\n- app\/packages\/users\/views<\/code><\/pre>\n\n\n\nAt this point, we are ready to check boundary violations in our application. To check violations we can runpackwerk update-deprecations<\/code> , this command will generate deprecated_references.yml<\/code> file for every package. In every file, we will find package name, type of violation, and file path. With all this information we know where the violation is happening and we can make a decision to resolve it.<\/p>\n\n\n\n![\"deprecated_references.yml\"](\"\/app\/uploads\/2024\/05\/4.png\" "\\"deprecated_references.yml")
<\/figure>\n\n\n\n# deprecated_references.yml\n\n.\n.\n.\n\napp\/packages\/repos:\n \"::Repo\":\n violations:\n - dependency\n files:\n - app\/packages\/users\/models\/user.rb<\/code><\/pre>\n\n\n\nTaking the example we are going to describe every part of the information generated
by Packwerk<\/strong>.<\/p>\n\n\n\n– app\/packages\/repos<\/code> – package where the constant violation is
found.<\/p>\n\n\n\n– ::Repo<\/code> – path to the file containing the violated constant.<\/p>\n\n\n\n– dependency<\/code> – a type of violation, either dependency or privacy.<\/p>\n\n\n\n– app\/packages\/users\/models\/user.rb<\/code> – path to the file containing the violated constant.<\/p>\n\n\n\nAs a final step in this section, don’t forget to add the new generated file paths to packwerk.ym<\/code>l and run validations again.<\/p>\n\n\n\nDependency visualization<\/h3>\n\n\n\n
With all the information in package.yml and deprecated_references.yml<\/code>we can then
visualize a graph of dependencies. In order to do that we need to add another gem, in this case we will use Pocky<\/a>.<\/p>\n\n\n\nRunning rake pocky:generate<\/code> we will generate a file called packwerk.png<\/code> where we can visualize our first graph of dependencies.<\/p>\n\n\n\nWith all the packages defined our graph will look like this.<\/p>\n\n\n\n![\"graph](\"\/app\/uploads\/2024\/05\/5.png\" "\\"graph")
<\/figure>\n\n\n\ndependencies already exist but it doesn’t mean they are accepted by Packwerk<\/strong>. To
accept a dependency we need to add dependencies configuration to the package.yml<\/code>
in every package. We will focus on mail_builders<\/code> since it’s a package without circular dependency. It’s worth mentioning that Packwerk<\/strong> won’t let us accept circular dependencies.<\/p>\n\n\n\n# app\/packages\/mail_builders\/package.yml\n\n```ruby\nenforce_privacy: false\nenforce_dependencies: true\ndependencies:\n- app\/packages\/docs\n- app\/packages\/issues\n- app\/packages\/repos<\/code><\/pre>\n\n\n\nAfter adding this configuration, Pocky<\/strong> will color the accepted dependencies using green.<\/p>\n\n\n\n![\"graph](\"\/app\/uploads\/2024\/05\/6.png\" "\\"graph")
<\/figure>\n\n\n\nWe can delete deprecated_references.yml<\/code> from app\/packages\/mail_builders<\/code> and run
packwerk update-deprecations<\/code> again. The file won’t be generated again since all the
violations were fixed for this package. It’s important to mention that even if we don’t Graph with accepted dependencies<\/p>\n\n\n\nRuby<\/a> on Rails modularization with Packwerk<\/strong> accept dependencies our application will still work as before, but now we have more
information to take decisions and refactor.<\/p>\n\n\n\nRemove circular dependencies<\/h3>\n\n\n\n
In our previous graph, we had a lot of circular dependencies that needed to be resolved somehow. We have different strategies to do that:<\/p>\n\n\n\n
– Do nothing,<\/p>\n\n\n\n
– Accept dependencies, Merge packages,<\/p>\n\n\n\n
– Move code<\/a> between packages,<\/p>\n\n\n\n– Duplicate a functionality, <\/p>\n\n\n\n
– Perform dependency injection or Dependency injection with typing.<\/p>\n\n\n\n
One issue here is that in order to do a proper refactor, we need to know the codebase. I’m not so familiar with the codebase of this project since I took it as an example, so for practical reasons we will go with the first strategy, do nothing. Even if we will avoid most of the refactoring, we want to work on the dependencies in the root<\/em> package.<\/p>\n\n\n\nThe root package contains all the glue from the Rails framework<\/strong>, all the classes we inherit from and make all work together. So, in order to solve the circular dependencies, we are going to create a new package called rails within the following steps:<\/p>\n\n\n\n\n- Move all the application_ files and folders from the app to
app\/packages\/rails<\/code>.<\/li>\n\n\n\n- Create a
package.yml<\/code> for the package with the same configuration as the previous packages.<\/li>\n\n\n\n- Add all the new file paths to
packwerk.yml<\/code>.<\/li>\n\n\n\n- Add
app\/packages\/rails<\/code> as a dependency from the rest of the packages.<\/li>\n<\/ol>\n\n\n\nOnce we create the package we will start to notice a lot of files that can be re-structured. After moving everything to the corresponding package and accepting
dependencies we will have a new structure and a cleaner graph.<\/p>\n\n\n\n![\"Package](\"\/app\/uploads\/2024\/05\/graph.png\" "\\"Package")
<\/figure>\n\n\n\n![\"Graph](\"\/app\/uploads\/2024\/05\/8.png\" "\\"Graph")
<\/figure>\n\n\n\nRemove dependencies from the root package<\/h3>\n\n\n\n
Now our graph looks much better would be great if we can remove all the dependencies from root package. If we check deprecated_references.yml in the root package, we will notice that most of them are from test<\/code> , lib\/tasks<\/code> , db<\/code> and config<\/code>
folder. In order to resolve these dependencies, we are going to create a test folder within every package. Having something like app\/packages\/users\/test<\/code>. Next, we are going to exclude lib\/tasks<\/code> , db<\/code> and config<\/code>among other folders from Packwerk<\/strong> analysis since those dependencies aren’t really important in our analysis and we don’t have an easy way to resolve them. We will add the following to our packwerk.yml<\/em>.<\/p>\n\n\n\nexclude:\n- \"{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}\/**\/*\"\n- \"lib\/tasks\/**\/*.rake\"<\/code><\/pre>\n\n\n\nAfter moving all the tests from root package and excluding the folders from the analysis we will have a new graph without root dependencies.<\/p>\n\n\n\n![\"Graph](\"\/app\/uploads\/2024\/05\/9.png\" "\\"Graph")
<\/figure>\n\n\n\nAs we can see, we still have circular dependencies inusers<\/code> , repos<\/code> , and docs<\/code> . Although we didn’t resolve them, we have important information to pass now. We know that every team<\/a> that performs changes in one of those packages will probably have to perform changes in the packages with the circular dependency. On the other hand, we know that a team can work on github_fetchers<\/code> solely, knowing what packages are
getting affected with the changes in every moment.<\/p>\n\n\n\nYou can find the final result of the project here<\/a>.<\/p>\n\n\n\nNext step<\/h3>\n\n\n\n
As a next step, you could enforce constant privacy in every package and expose only the public API that will be accessible from other packages. You can easily configure where your API will be placed in package.yml<\/em>.<\/p>\n\n\n\nenforce_privacy: true\nenforce_dependencies: true\npublic_path: my\/custom\/path\/<\/code><\/pre>\n\n\n\n <\/code><\/p>\n\n\n\nConclusions<\/h2>\n\n\n\n
Packwerk<\/strong> gives us a lot of information about our application and with that information we can take decisions to improve the workflow of our teams. Although the process seemed to be long and with a lot of configurations, it doesn’t have to be like that always. We can start creating packages only for the new code added to our application and then modularize gradually. So now we can start to talk about Gradual Modularization this is the concept introduced by Stephan Hagemann “We can, for the first time, decide to start modularizing a portion of the code in an aspirational way… This allows us to create a gradually expanding support system towards a better application structure”.<\/em><\/p>\n\n\n\nSources<\/h2>\n\n\n\n\n- Gradual Modularization for Ruby on Rails – Stephan Hagemann<\/a><\/li>\n\n\n\n
- Enforcing Modularity in Rails Apps with Packwerk<\/a><\/li>\n\n\n\n
- Packwerk Github<\/a><\/li>\n\n\n\n
- Source Code of the Article<\/a><\/li>\n<\/ol>\n\n\n\n
![\"Digital](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/figure>\n\n\n\nRead More<\/strong><\/p>\n\n\n\nGraphQL Ruby. What about performance?<\/a><\/p>\n\n\n\n