Gradual Modularization for Ruby and Rails
Gradual Modularization for Ruby and Rails
Improve collaboration, system design, and flexibility
About the Book
For the longest time, Ruby and Rails developers had gems and engines as their main tools for creating structure to manage large-scale structures within their applications. This book is about a new tool in their toolbelt: packages.
Based on the work on packwerk by Shopify packages allow a much more fluid move to modularization then components ever did. The effects are astounding: discussions about where to draw boundaries can be far less technical and focus more on the business because the underlying technology gets out of the way.
The concept underlying this is gradual modularization, which the author expects we will see spread into other languages and frameworks over the coming years. Why? Because gradual modularization allows for a not-before seen level of approachability and flexibility to modularization work. Work that required difficult decisions that were hard to reverse changes. Those decisions are now the extreme points on a spectrum of options where the right thing for the team can be somewhere in between.
About the Author
Table of Contents
- Acknowledgments
-
1 Introduction to Package-based Rails Applications
- 1.1 The inescapable challenges with components
-
1.2 Component-based Challenges
- 1.2.1 External dependency drift
- 1.2.2 Configuration drift
- 1.2.3 Global impact of local changes
-
2 Getting started with packaging in a Rails application
- 2.1 Let’s get started
-
2.2 From one to many packages
- 2.2.1 Packwerk packages vs gems as components
- 2.2.2 A completely “packagified” application
- 2.2.3 Introducing app/packages
- 2.2.4 Getting things to work
- 2.2.5 Making Packwerk packages
- 2.2.6 Visualizing dependencies
- 2.3 Accepting the intended dependencies - explicitly adding package dependencies
- 2.4 Removing the circular dependencies - creating rails_shims package
- 2.5 Analyzing and removing root dependencies (almost) - Aligning app and test code
- 2.6 Removing all dependencies from the root package
- 2.7 Simplifying package loading
- 2.8 Recapping differences and similarities to components
-
3 Gradual Modularization: A New Model for Application Composition
- 3.1 Gradual Typing as a Role Model
- 3.2 Commonalities of previous modularization approaches
-
3.3 Gradularity - Modularization Game Changer
- 3.3.1 Enforce Visibility
- 3.3.2 Allow privacy circumvention
- 3.3.3 API versioning
- 3.3.4 Enforcing a package namespace
- 3.3.5 Enforcing a separate database
- 3.3.6 Enforcing a typed API
- 3.3.7 Enforcing proper documentation
- 3.3.8 Configurable failure modes
- 3.3.9 Here is my code, run it in the cloud for me, I do not care how
- 3.3.10 Analyze to modularize the right stuff
- 3.3.11 Caveats
- 3.3.12 Managing the caveats
-
4 Making Components Work with Packages
- 4.1 Engines
-
4.2 Gems
- 4.2.1 Converting the gem fully into an engine
- 4.2.2 Converting the gem into an engine (as little as possible!)
-
5 Dependency Violation Management Refactorings
- 5.1 Do absolutely nothing
- 5.2 Accept the dependency
- 5.3 Merge the two packages
- 5.4 Split the violated package
- 5.5 Move the code between packages
- 5.6 Duplicate the functionality
- 5.7 Abstract away the dependency
-
5.8 Dependency injection
- 5.8.1 Naive dependency injection
- 5.8.2 Dependency injection with typing
- 5.8.3 Dependency injection with typing and type abstraction
- 5.9 Dependency Location - The service locator pattern
-
5.10 Emit and listen to events
- 5.10.1 To event or not to event - and where?
- 5.10.2 Calculating backend responses with events
- 5.10.3 Determining where to send responses
- 5.10.4 Wiring backend and frontend together
- 5.10.5 The package effect of eventing
- 5.11 Beyond dependency refactorings
-
6 Privacy Violation Management Refactorings
-
6.1 Packages without consumers should protect their public API
- 6.1.1 The root package
- 6.1.2 The UI and admin packages
-
6.1.3
packages/prediction_interfaceand interface classes
- 6.2 Expose existing service classes
- 6.3 Expose existing service classes
- 6.4 ActiveRecord handled naively
-
6.5 Hide ActiveRecord
-
6.5.1 A new form of
Team -
6.5.2 A
TeamRepositoryto manage teams - 6.5.3 Migrating consumers to the new API
-
6.5.1 A new form of
-
6.1 Packages without consumers should protect their public API
-
7 RubyAtScale
- 7.1 The giants whose shoulders we stand on
- 7.2 Gusto’s RubyAtScale work supporting Gradual Modularity
- 7.3 Stimpack
- 7.4 Code Teams
- 7.5 ParsePackwerk
- 7.6 Code ownership
- 7.7 PackageProtections
- 7.8 Danger::Packwerk
- 7.9 ModularizationStatistics
- 7.10 Honorable mentions: More of Gusto’s RubyAtScale
- 7.11 The Structure of RubyAtScale
-
8 Measure Modularization Progress
-
8.1 Basic technical measures of modularization progress
- 8.1.1 How modularized is the app?
- 8.1.2 Is there an adequate amount of packages?
- 8.1.3 How much are packages owned by only one team?
- 8.1.4 How discerning is the package dependency graph?
- 8.1.5 Basic technical measures create a path
-
8.2 Refining technical measures of modularization progress
- 8.2.1 How many packages protect themselves from breaking their own stated dependencies?
- 8.2.2 How many packages protect themselves against privacy violations?
- 8.2.3 How many packages are operating in their own namespace?
- 8.2.4 How many packages protect themselves against untyped APIs?
-
8.3 Growing the list of technical measures your organization can support
- 8.3.1 Adding your own protections
-
8.4 Sociotechnical measures that go beyond modularization
- 8.4.1 High-level vs low-level metrics (and tests)
- 8.4.2 The DevOps Research and Assessment metrics
-
8.1 Basic technical measures of modularization progress
-
9 How to Create Modularization Progress
- 9.1 Where to get started
-
9.2 Going it alone - What individuals or teams can do
- 9.2.1 Move files into a package
- 9.2.2 Align on root namespace
- 9.2.3 Create package API
- 9.2.4 Document package API
- 9.2.5 Type package API
- 9.2.6 Remove dependency violation
- 9.3 Move everything, all at once
- 9.4 Hackathons
- 9.5 Kudos
- 9.6 Dedicated Project Team
- 9.7 Champions
- 9.8 Vision
- 9.9 How to use technical modularization metrics
- Notes
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
