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
- Introduction
-
1 The Problems with Component-based Rails and Why Today’s Tooling Is More Powerful
- 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 Making Components Work with Packages
- 3.1 Engines
-
3.2 Gems
- 3.2.1 Converting the gem fully into an engine
- 3.2.2 Converting the gem into an engine (as little as possible!)
-
4 Beyond Dependencies: Making More Modularization Gradual
- 4.1 Gradual Modularization as A New Model for Application Composition
- 4.2 Gradual Typing as a Role Model
- 4.3 Commonalities of previous modularization approaches
- 4.4 Gradularity - Modularization Game Changer
- 4.5 Motivating More Modularity
- 4.6 Privacy
- 4.7 Architectural layers
- 4.8 Visibility
- 4.9 Folder visibility
- 4.10 API Documentation
- 4.11 API Typing
- 4.12 Package Namespace
- 4.13 API Structure
- 4.14 Missing pieces
-
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.6 Where are technical refactorings and to which end
-
6.1 Packages without consumers should protect their public API
-
7 RubyAtScale
- 7.1 The giants whose shoulders we stand on
- 7.2 Packwerk Visual Studio Code Plugin
- 7.3 Danger! Packwerk
- 7.4 Code Teams
- 7.5 ParsePackwerk and Packs::Specification
- 7.6 Code Ownership
- 7.7 Packs
- 7.8 Package Statistics
- 7.9 Honorable mentions: More of Gusto’s RubyAtScale
-
8 Measuring Modularization Progress
-
8.1 Basic technical measures of modularization progress
- 8.1.1 How modularized is the app?
- 8.1.2 Are 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 for improvement
-
8.2 Refining technical measures of modularization progress
- 8.2.1 How many packages use a given structure enforcement?
- 8.2.2 Usage metrics for package-quality metrics
- 8.3 How to use technical modularization metrics
-
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 (DORA) metrics
- 8.4.3 The SPACE framework for Developer Productivity
-
8.1 Basic technical measures of modularization progress
-
9 How to Create Modularization Progress
- 9.1 To start on a modularization journey
- 9.2 Skills - Getting started
-
9.3 Vision - Apps and libraries
- 9.3.1 Applications and Libraries - aspirationally!?
- 9.3.2 Monoliths and package types
- 9.3.3 What makes a package extractable
- 9.3.4 Extractable library
- 9.3.5 Extractable applications
- 9.3.6 How far to go
- 9.3.7 The vision behind the vision
-
9.4 Action Plan
- 9.4.1 Strider Bikes
- 9.4.2 Strider bikes - what now?
- 9.4.3 Fragments of an action plan
- 9.5 Resources
- 9.6 Incentives
-
10 Polyglot Persistence, Polyglot Approaches
- 10.1 Domain-appropriate implementation choices
- 10.2 Domain-specific requirements balanced with application standardization
-
10.3 Using Eventide to create a backend component
- 10.3.1 An autonomous, event-sourced component for predictions
-
10.4 Using Hanami inside Rails
- 10.4.1 I’ll take a slice!
- 10.4.2 A slice is a package
- 10.5 Conclusion
-
11 Archive. Gradual Modularization: A New Model for Application Composition
-
- 11.0.1 Enforce Visibility
- 11.0.2 Allow privacy circumvention
- 11.0.3 API versioning
- 11.0.4 Enforcing a package namespace
- 11.0.5 Enforcing a separate database
- 11.0.6 Enforcing a typed API
- 11.0.7 Enforcing proper documentation
- 11.0.8 Configurable failure modes
- 11.0.9 Here is my code, run it in the cloud for me, I do not care how
- 11.0.10 Analyze to modularize the right stuff
- 11.0.11 Caveats
- 11.0.12 Managing the caveats
-
- 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.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $14 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
