How I architected my big Rails app for success!
summary
Claims a single Rails app split into web and domain engines with four engines plus one gem handling SMS, uses namespaced tables and keeps migrations inside engines so a table can be moved by copying its migrations, and runs tests per-engine to only run changed subsystems. Team ramps to 10 Rails and 4 iOS devs over an eight month rebuild, sees a slow start with heavy refactoring (~1/3 time) but achieves parallel work, easier scaling and faster targeted tests in the long run.
AI-written summary · about
chapters (13)
- 0:00Start
- 3:41long project
- 4:29big bang release
- 4:53a grain of salt
- 6:57a little background
- 18:55migrations inside engines
- 19:54one table per migration
- 20:34testing the engines in isolation
- 21:20engines the right way
- 23:00domain api
- 27:12no circular dependencies
- 29:08how did it work out?
- 30:43thumbs up
related talks
37mHow I Architected My Big Rails App For Success
35mWrangling Large Rails Codebases
33mRefactoring Towards Component-based Rails Architectures
42mHow Rails fosters a diverse and competitive tech ecosystem in the era of big tech
51mRails Engines Patterns
28mBringing Your Rails Monolith Along As The Business Grows
38mAll you need is Rails (Engines): Compartmentalising your Monolith
40mOptimize for developer speed