Gradual Modularization for Ruby and Rails

Acknowledgments

Introduction

1The Problems with Component-based Rails and Why Today’s Tooling Is More Powerful

1. 1.1The inescapable challenges with components
2. 1.2Component-based Challenges
3. 1.2.1External dependency drift
4. A story of dependency drift: “Oops! We just lost two orders of magnitude”
5. 1.2.2Configuration drift
6. A story of configuration drift: Rails initializers doing what?
7. 1.2.3Global impact of local changes

2Getting started with packaging in a Rails application

1. Delete the app folder?
2. 2.1Let’s get started
3. Comparing to CBRA
4. 2.2From one to many packages
5. 2.2.1Packwerk packages vs gems as components
6. Example package structure
7. 2.2.2A completely “packagified” application
8. 2.2.3Introducing app/packages
9. 2.2.4Getting things to work
10. 2.2.5Making Packwerk packages
11. Not all violations are created equal: ActiveRecord oh my
12. 2.2.6Visualizing dependencies
13. Comparing to CBRA
14. 2.3Accepting the intended dependencies - explicitly adding package dependencies
15. 2.4Removing the circular dependencies - creating rails_shims package
16. 2.5Analyzing and removing root dependencies (almost) - Aligning app and test code
17. Alternative structures
18. 2.6Removing all dependencies from the root package
19. 2.7Simplifying package loading
20. 2.8Recapping differences and similarities to components

3Making Components Work with Packages

1. 3.1Engines
2. 3.2Gems
3. 3.2.1Converting the gem fully into an engine
4. 3.2.2Converting the gem into an engine (as little as possible!)

4Beyond Dependencies: Making More Modularization Gradual

1. 4.1Gradual Modularization as A New Model for Application Composition
2. 4.2Gradual Typing as a Role Model
3. 4.3Commonalities of previous modularization approaches
4. 4.4Gradularity - Modularization Game Changer
5. 4.5Motivating More Modularity
6. 4.6Privacy
7. 4.7Architectural layers
8. 4.8Visibility
9. 4.9Folder visibility
10. 4.10API Documentation
11. 4.11API Typing
12. 4.12Package Namespace
13. 4.13API Structure
14. 4.14Missing pieces

5Dependency Violation Management Refactorings

1. 5.1Do absolutely nothing
2. 5.2Accept the dependency
3. 5.3Merge the two packages
4. 5.4Split the violated package
5. 5.5Move the code between packages
6. 5.6Duplicate the functionality
7. 5.7Abstract away the dependency
8. 5.8Dependency injection
9. 5.8.1Naive dependency injection
10. 5.8.2Dependency injection with typing
11. 5.8.3Dependency injection with typing and type abstraction
12. 5.9Dependency Location - The service locator pattern
13. 5.10Emit and listen to events
14. 5.10.1To event or not to event - and where?
15. 5.10.2Calculating backend responses with events
16. 5.10.3Determining where to send responses
17. 5.10.4Wiring backend and frontend together
18. 5.10.5The package effect of eventing
19. 5.11Beyond dependency refactorings

6Privacy Violation Management Refactorings

1. 6.1Packages without consumers should protect their public API
2. 6.1.1The root package
3. 6.1.2The UI and admin packages
4. 6.1.3packages/prediction_interface and interface classes
5. 6.2Expose existing service classes
6. 6.3Expose existing service classes
7. 6.4ActiveRecord handled naively
8. 6.5Hide ActiveRecord
9. 6.5.1A new form of Team
10. 6.5.2A TeamRepository to manage teams
11. 6.5.3Migrating consumers to the new API
12. 6.6Where are technical refactorings and to which end

7RubyAtScale

1. 7.1The giants whose shoulders we stand on
2. 7.2Packwerk Visual Studio Code Plugin
3. 7.3Danger! Packwerk
4. 7.4Code Teams
5. 7.5ParsePackwerk and Packs::Specification
6. 7.6Code Ownership
7. 7.7Packs
8. 7.8Package Statistics
9. 7.9Honorable mentions: More of Gusto’s RubyAtScale

8Measuring Modularization Progress

1. 8.1Basic technical measures of modularization progress
2. 8.1.1How modularized is the app?
3. 8.1.2Are there an adequate amount of packages?
4. 8.1.3How much are packages owned by only one team?
5. 8.1.4How discerning is the package dependency graph?
6. 8.1.5Basic technical measures create a path for improvement
7. 8.2Refining technical measures of modularization progress
8. 8.2.1How many packages use a given structure enforcement?
9. How many packages protect themselves from being used unintentionally?
10. 8.2.2Usage metrics for package-quality metrics
11. 8.3How to use technical modularization metrics
12. 8.4Sociotechnical measures that go beyond modularization
13. 8.4.1High-level vs low-level metrics (and tests)
14. 8.4.2The DevOps Research and Assessment (DORA) metrics
15. 8.4.3The SPACE framework for Developer Productivity

9How to Create Modularization Progress

1. 9.1To start on a modularization journey
2. Managing a multitude of options
3. 9.2Skills - Getting started
4. 9.3Vision - Apps and libraries
5. 9.3.1Applications and Libraries - aspirationally!?
6. 9.3.2Monoliths and package types
7. 9.3.3What makes a package extractable
8. 9.3.4Extractable library
9. 9.3.5Extractable applications
10. 9.3.6How far to go
11. 9.3.7The vision behind the vision
12. 9.4Action Plan
13. 9.4.1Strider Bikes
14. 9.4.2Strider bikes - what now?
15. 9.4.3Fragments of an action plan
16. 9.5Resources
17. 9.6Incentives

10Polyglot Persistence, Polyglot Approaches

1. 10.1Domain-appropriate implementation choices
2. 10.2Domain-specific requirements balanced with application standardization
3. 10.3Using Eventide to create a backend component
4. 10.3.1An autonomous, event-sourced component for predictions
5. 10.4Using Hanami inside Rails
6. 10.4.1I’ll take a slice!
7. 10.4.2A slice is a package
8. 10.5Conclusion

11Archive. Gradual Modularization: A New Model for Application Composition

1. 11.0.1Enforce Visibility
2. 11.0.2Allow privacy circumvention
3. External and internal tests in Go
4. 11.0.3API versioning
5. 11.0.4Enforcing a package namespace
6. 11.0.5Enforcing a separate database
7. 11.0.6Enforcing a typed API
8. 11.0.7Enforcing proper documentation
9. 11.0.8Configurable failure modes
10. 11.0.9Here is my code, run it in the cloud for me, I do not care how
11. 11.0.10Analyze to modularize the right stuff
12. 11.0.11Caveats
13. 11.0.12Managing the caveats