Gradual Modularization for Ruby and Rails
$24.99
Minimum price
$29.99
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 stephanhagemann.com.

Table of Contents

  • Acknowledgments
  • 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 Architecture
    • 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_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
    • 6.6 Where are technical refactorings and to which end
  • 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 Sentiment Surveys within the engineering organization
  • 9 Gradual Modularization: A New Model for Application Composition
    •  
      • 9.0.1 Enforce Visibility
      • 9.0.2 Allow privacy circumvention
      • 9.0.3 API versioning
      • 9.0.4 Enforcing a package namespace
      • 9.0.5 Enforcing a separate database
      • 9.0.6 Enforcing a typed API
      • 9.0.7 Enforcing proper documentation
      • 9.0.8 Configurable failure modes
      • 9.0.9 Here is my code, run it in the cloud for me, I do not care how
      • 9.0.10 Analyze to modularize the right stuff
      • 9.0.11 Caveats
      • 9.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...

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 $13 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