Gradual Modularization for Ruby and Rails
Minimum price
Suggested price

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.

  • Share this book

  • Categories

    • Ruby on Rails
    • Software Engineering
    • Software Architecture
    • Computers and Programming
    • Ruby
  • Feedback

    Email the Author(s)

About the Author

Stephan Hagemann
Stephan Hagemann

Stephan leads the product infrastructure engineering team at Gusto. Gusto has quite a bit of Ruby on Rails in the software behind their offerings and provides the perfect ground for the analysis of complex applications due to "Payroll" being both a deep and very wide domain. And Gusto is a lot more than payroll.

Stephan is the author of Component-based Rails Applications in which he lays out the previous iteration of Ruby and Rails modularization based on gems and engines. He is currently working on a new book called Gradual Modularization for Ruby and Rails, which improves on his previous ideas by reducing the cost of the needed work and increasing the opportunities for benefiting from it.

Find out more about Stephan at

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_interface and 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 TeamRepository to manage teams
      • 6.5.3 Migrating consumers to the new 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
  • 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

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub