Morning Keynote
summary
Argues that splitting a Rails codebase into labeled gems and Rails engines gives provable boundaries, per-component tests and a build script that aggregates results, and lets teams change only impacted parts. Demonstrates tooling: bundler, engine mounting, dummy app, trueskill gem, and per-component test scripts. Notes surprising counts: a generated gem skeleton ~88 lines whereas a Rails engine skeleton ~528 lines, and real apps can reach 60–70 components. Shows it works but is costly and needs better tooling.
AI-written summary · about
chapters (5)
- 0:00Start
- 4:58As a language, Ruby does not have components
- 15:09Structural Costs + Benefits
- 19:32WHAT IS A COMPONENT?
- 37:44Fix cross-component dependency versioning
related talks
35mWrangling Large Rails Codebases
33mRefactoring Towards Component-based Rails Architectures
38mAll you need is Rails (Engines): Compartmentalising your Monolith
51mRails Engines Patterns
01h 28mGet started with Component-based Rails applications!
32mHow I architected my big Rails app for success!
40mMonoliths Between Microservices
17mDesigning software that maximizes developer productivity
