What do you think?
Rate this book
Component-Based Rails Applications: Large Domains Under Control
Use Components to Improve Maintainability, Reduce Complexity, and Accelerate Testing in Large Rails Applications “This book gives Ruby pros a comprehensive guide for increasing the sophistication of their designs, without having to forsake the principles of elegance that keep them in our corner of the software world.” –Obie Fernandez, author, The RailsTM 5 Way, Fourth Edition As Rails applications grow, even experienced developers find it difficult to navigate code bases, implement new features, and keep tests fast. Components are the solution, and Component-Based Rails Applications shows how to make the most of them. Writing for programmers and software team leads who are comfortable with Ruby and Rails, Stephan Hagemann introduces a practical, start-to-finish methodology for modernizing and restructuring existing Rails applications. One step at a time, Hagemann demonstrates how to revamp Rails applications to exhibit visible, provably independent, and explicitly connected parts–thereby simplifying them and making them far easier for teams to manage, change, and test. Throughout, he introduces design concepts and techniques you can use to improve applications of many kinds, even if they weren’t built with Rails or Ruby. If you’re ready to simplify and revitalize your complex Rails systems, you’re ready for Component-Based Rails Applications . Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.
304 pages, Paperback
Published June 22, 2018
16 people are currently reading
33 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
September 27, 2020
Ruby on Rails's
convention over configuration
lets you tap a lot of functionality with a small amount of code. If you follow the patterns, it will figure things out for you. Everything can reference anything, to make it even easier on developers. It works really well at smaller scales, but it fails to provide strong boundaries for larger teams to stay decoupled for one another.
Someone had mentioned Rails engines to me before, but the documentation is hard to break through. This book by Hagemann does a much better job of explaining how gems, plugins, and engines can provide a way to decouple parts of the code. With some careful attention to dependencies in Gemfiles, you can use them to provide the strong boundaries I said were missing earlier. Components give you all the freedoms of Rails internally and provide a degree of isolation across their boundaries. But in doing so, we are going against the grain of how Rails wants to do things.
Extracting components from an existing application can feel like hacking, at times. Hagemann sometimes takes it a step further, like his shell scripts that build and run tests. These parts of the text would have benefited from more explanation of how Rails wants things to behave and how the "hacks" work with it or against it. For example, when shoehorning the application into Heroku (and nice touch with Cloud Foundry). We use components to help with maintenance, but we are also paying a tax with all this hacking. We need to keep this tax well below the gains from the component-based architecture.
Hagemann's definition of what constitutes a component is a little academic and arbitrary. For instance, he insists on the absence of circular dependencies. Ruby's Bundler can't handle circular dependencies, but that doesn't mean that an arbitrary definition of components requires it too. There are a few claims like this that could have used more justification.
I did appreciate how, in Chapter 5, Hagemann builds out a one-time script to extract a component. By getting the script to do everything needed for the extraction, he can work on impediments while development of the app is still going on. Once the script is ready, you only need to freeze development long enough to run the script.
A book tied to a specific technology is at the mercy of evolution. This book uses an early version of Rails 5, and we're at Rails 6, now. After more than an hour trying to get the assets in an early example to behave, I had to give up and open a ticket in the book's GitHub.
The book has a quick example of how components can fit in hexagonal architecture or in DCI. In doing so, it shows how these architectures go even more against the grain of Rails. They require a lot of boilerplate to fully isolate the concerns, and use a lot of data transfer objects. Rails specifically aims for the opposite: let the framework handle the drudgery, so you can focus on the fun part. DHH wrote a lengthy complaint against hexagonal architecture.
I now work with Stephan Hagemann at Gusto. Components are one tool in our toolbox as we look for ways to modularize our monoliths and unleash the potential of our developers.
Someone had mentioned Rails engines to me before, but the documentation is hard to break through. This book by Hagemann does a much better job of explaining how gems, plugins, and engines can provide a way to decouple parts of the code. With some careful attention to dependencies in Gemfiles, you can use them to provide the strong boundaries I said were missing earlier. Components give you all the freedoms of Rails internally and provide a degree of isolation across their boundaries. But in doing so, we are going against the grain of how Rails wants to do things.
Extracting components from an existing application can feel like hacking, at times. Hagemann sometimes takes it a step further, like his shell scripts that build and run tests. These parts of the text would have benefited from more explanation of how Rails wants things to behave and how the "hacks" work with it or against it. For example, when shoehorning the application into Heroku (and nice touch with Cloud Foundry). We use components to help with maintenance, but we are also paying a tax with all this hacking. We need to keep this tax well below the gains from the component-based architecture.
Hagemann's definition of what constitutes a component is a little academic and arbitrary. For instance, he insists on the absence of circular dependencies. Ruby's Bundler can't handle circular dependencies, but that doesn't mean that an arbitrary definition of components requires it too. There are a few claims like this that could have used more justification.
I did appreciate how, in Chapter 5, Hagemann builds out a one-time script to extract a component. By getting the script to do everything needed for the extraction, he can work on impediments while development of the app is still going on. Once the script is ready, you only need to freeze development long enough to run the script.
A book tied to a specific technology is at the mercy of evolution. This book uses an early version of Rails 5, and we're at Rails 6, now. After more than an hour trying to get the assets in an early example to behave, I had to give up and open a ticket in the book's GitHub.
The book has a quick example of how components can fit in hexagonal architecture or in DCI. In doing so, it shows how these architectures go even more against the grain of Rails. They require a lot of boilerplate to fully isolate the concerns, and use a lot of data transfer objects. Rails specifically aims for the opposite: let the framework handle the drudgery, so you can focus on the fun part. DHH wrote a lengthy complaint against hexagonal architecture.
I now work with Stephan Hagemann at Gusto. Components are one tool in our toolbox as we look for ways to modularize our monoliths and unleash the potential of our developers.
October 31, 2018
I liked the idea of encapsulating code into isolated components, although I was looking for a different approach for "componentization" than what CBRA promotes. In CBRA, your components would be coupled but in an explicit way. You'll have different components for UI, business, application and persistence logic. What I was looking is an architecture more similar to microservices. I want to start with monolith but built it with decoupled components each of which represents a sub-domain in terms of DDD (not sure if I'm right about DDD stuff, still have to read a book about it :)).
Nevertheless, I found this book useful for presenting the idea of isolated components via rails engines and a practical guide on how to start with engines if you never did it before. However, an author uses several non-mainstream techniques (like writing factories for specs by hand instead of using factory_bot or similar gem and using shell scripts for running specs instead of rake tasks) which don't cover issues that you'll encounter if you'll go the mainstream way (the most painful issues for me are all about tests for now). You'll encounter many obstacles in either way but the author tries to cover all the issues while doing CBRA.
All in all, I'm glad I've bought and read that book and I'm thankful to the author.
Nevertheless, I found this book useful for presenting the idea of isolated components via rails engines and a practical guide on how to start with engines if you never did it before. However, an author uses several non-mainstream techniques (like writing factories for specs by hand instead of using factory_bot or similar gem and using shell scripts for running specs instead of rake tasks) which don't cover issues that you'll encounter if you'll go the mainstream way (the most painful issues for me are all about tests for now). You'll encounter many obstacles in either way but the author tries to cover all the issues while doing CBRA.
All in all, I'm glad I've bought and read that book and I'm thankful to the author.
February 13, 2022
Didn’t get a lot of new insights out of this book.
On the positive side it walks through a lot of mechanics while decomposing a Rails app into engines. And it does this very in depth.
On the other hand there were many thingsI didn‘t like too much reading this book:
I‘m not a big fan of turning a rails app into too fine grained components. For example I don’t see big advantages in having many small frontend components/engines in a rails app. The frontend world nowadays has its own component systems.
This book is also pre-Packwerk. So it doesn‘t cover tooling that exists today. What I like about Packwerk that CBRA doesn‘t seem to have is the best explicit handling of „public“ APIs between components and violations between them. This book goes more into an all or nothing approach. The Packwork one seems to be more pragmatic to me.
Discussing hexagonal architecture and DCI also doesn’t end up on the pro side either. I‘ve seen Rails apps in the past that tried to apply DCI, ports&adapters and monads. Let’s say these apps ended up being rewritten to a simpler way at some point, because teams and especially new team members struggled with those architectures foreign to Rails. KISS rules for a reason, at least for the kind of applications I‘m usually involved with
All in all something around 2,5 stars
On the positive side it walks through a lot of mechanics while decomposing a Rails app into engines. And it does this very in depth.
On the other hand there were many thingsI didn‘t like too much reading this book:
I‘m not a big fan of turning a rails app into too fine grained components. For example I don’t see big advantages in having many small frontend components/engines in a rails app. The frontend world nowadays has its own component systems.
This book is also pre-Packwerk. So it doesn‘t cover tooling that exists today. What I like about Packwerk that CBRA doesn‘t seem to have is the best explicit handling of „public“ APIs between components and violations between them. This book goes more into an all or nothing approach. The Packwork one seems to be more pragmatic to me.
Discussing hexagonal architecture and DCI also doesn’t end up on the pro side either. I‘ve seen Rails apps in the past that tried to apply DCI, ports&adapters and monads. Let’s say these apps ended up being rewritten to a simpler way at some point, because teams and especially new team members struggled with those architectures foreign to Rails. KISS rules for a reason, at least for the kind of applications I‘m usually involved with
All in all something around 2,5 stars
October 22, 2024
It's a good read to expand your concepts "library" and expose you to other ways of building with Rails. As for "real-world" application of these concepts, it's tough to justify deviating so much from Rails' way, as hiring and training new developers will be even more challenging than it already is.
April 14, 2019
Quick read. Examples are nice since they are fresh, likely won't age well with time.
September 22, 2024
It's written fine but the concept of CBRA I'm not on board with at all.
Displaying 1 - 6 of 6 reviews