book

Component-Based Rails Applications: Large Domains Under Control

by Stephan Hagemann

June 2018

Intermediate to advanced

304 pages

8h 29m

English

Addison-Wesley Professional

Read now

Unlock full access

1.1 Component-Based Rails1.1.1 What Component-Based Rails Is1.2 Benefits of Component-Based Applications1.2.1 Improved Communication of Intent1.2.2 Improved Collaboration Among Developers1.2.3 Improved Creation of Features1.2.4 Improved Maintenance of the Application1.2.5 Improved Comprehension of Application Parts1.2.6 History Repeating?1.3 Component-Based Ruby1.4 The Application Continuum1.5 Related Works
2.1 The Entire App Inside a Component2.2 ActiveRecord and Handling Migrations within Components2.2.1 Installing Engine Migrations with Rake2.2.2 Loading Engine Migrations in Place2.2.3 Known Issues2.3 Handling Dependencies within Components2.3.1 Using path Blocks for Specifying CBRA Dependencies2.3.2 Adding a Regular Gem: slim—Different Templating2.3.3 Locking Down Gem Versions2.3.4 Adding the Development Version of a Gem: Trueskill—A Rating Calculation Library2.3.5 Adding Predictions to the App
3.1 Testing a Component3.1.1 ActiveRecord Model Specs3.1.2 Non-ActiveRecord Model Specs3.1.3 Controller Specs3.1.4 Helper Specs3.1.5 Feature Specs3.2 Testing the Main Application3.2.1 What to Test in the Main App3.2.2 How to Put Everything Together3.2.3 How to Set Up a Continuous Integration (CI) Server3.3 Asset Loading for Components3.3.1 Production-Ready Assets3.4 Switching Databases3.5 Deploying to Platforms-as-a-Service3.5.1 Deploying to Heroku3.5.2 Deploying to Pivotal Web Services3.6 Updating Application Dependencies3.6.1 Updating the Bundle in All Components3.6.2 Updating Every Component’s Gem Version3.6.3 Updating Rails3.6.4 Long-Running Dependency Updates3.6.5 Listing a Dependency Only Once3.7 Proposal for a Different Application Root—Showcasing the Difference of Components’ Structure3.7.1 Why Would I Want to Change That?3.7.2 How CBRA Can Change How I Present and Perceive My App3.7.3 Making CI and PaaS Work with the New Structure3.7.4 What Is Next?
4.1 Determining What to Extract: Bottom-Up4.2 Refactoring: Extract Domain Gem—Predictor4.2.1 Fixing Inside-Out: Making AppComponent Work Again4.2.2 Last Step: Ensure That the App Works4.2.3 Summary of Bottom-Up Component Extractions4.3 Determining What to Extract: Top-Down4.3.1 Unclear Dependency Direction4.3.2 Not Everything Needs Predictor4.3.3 Implications of the First Set of Extractions4.3.4 Problem with the Current Solution4.3.5 Reducing Needed Dependencies4.4 Refactoring: Pulling Up a UI Component—TeamsAdmin, GamesAdmin, PredictionUI, WelcomeUI4.4.1 Generate4.4.2 Move4.4.3 Fix, Part 1: Reusing Test Helpers4.4.4 Fix, Part 2: Routing Issues4.4.5 Fix, Part 3: The Container Application4.4.6 An Explicitly Contracted Global Navigation4.5 Refactoring: Pushing Down a Model Component—Teams, Games4.5.1 Getting Away with Less4.5.2 Fixing Teams Tests4.5.3 Fixing Everything Else4.6 Refactoring: Improve Naming of Component—AppComponent to WebUI4.6.1 Whatever Happened to AppComponent?4.6.2 Refactoring Component Names4.6.3 Refactoring a Component Name Throughout the Application4.6.4 An Even More Mechanical Approach4.7 More Component Refactoring Patterns4.7.1 Splitting One Component in Two: Disentangling Unrelated Concepts4.7.2 API Component4.7.3 Third-Party Service Adapter4.7.4 Common Functionality Component
5.1 Small Steps5.2 One Big Step5.2.1 Prerequisites5.2.2 Script This!5.2.3 A Scripted Refactoring5.2.4 Cleaning Up Persistence5.2.5 Using Persistence5.2.6 Summary
6.1 Hexagonal Architecture6.1.1 Hexagonal Architecture and CBRA6.1.2 Implementing Hexagonal Rails with CBRA6.1.3 Teasing Out an Adapter in the Frontend6.1.4 A Repository for Data Storage6.1.5 Swappable Data Storage6.1.6 Summary6.2 Data-Context-Integration (DCI)6.2.1 DCI and CBRA6.2.2 Implementing DCI with CBRA6.2.3 Summary
7.1 Kotlin, Java, and Gradle7.2 .NET / C7.3 Conclusion
A.1 Plain versus --full versus --mountable EnginesA.1.1 GemA.1.2 Plain PluginA.1.3 Full EngineA.1.4 Mountable EngineA.2 How Do Engine Routes and Engine Mounting Work?A.2.1 Engines as SubdomainsA.2.2 Engines Are (Unfortunately) SingletonsA.3 Additional Testing with Older Versions of RailsA.3.1 View SpecsA.3.2 Routing Specs

Content preview from Component-Based Rails Applications: Large Domains Under Control

“A good architecture maximizes the number of decisions not made. It’s the purpose of an architecture to prevent you from making decisions. It is to keep your options open for as long as those options can be open.”

—From Robert Martin’s Ruby Midwest 2011 keynote, “Architecture the Lost Years.” https://www.youtube.com/watch?v=WpkDN78P884 at 57:18

“Intelligence tries to maximize future freedom of action and keep options open.”

—From Alex Wissner-Gross’s TED talk, “A New Equation for Intelligence.” http://www.ted.com/talks/alex_wissner_gross_a_new_equation_for_intelligence at 5:18

“I like to draw these lines. Architecture is the art of drawing lines. With the interesting rule that once you have drawn the lines, all the dependencies that cross that ...