Organize your Rails codebase with aaa engines
We give each feature a directory containing the app code, tests, migrations, and routes specific to it. It looks like a mini-rails app that only contains the code related to that feature.
Working with these mini-rails apps is a breeze! You can fully expand the app/* directories, and they all neatly fit in the file explorer on the left-hand-side of your screen. It’s so satisfying to navigate such a small set of files.
I helped extract such engines on two large apps, and they were enthusiastically adopted. It doesn’t require much effort as long as you move files around without attempting to isolate the engine from the rest of the app.
I worked on an application where that directory was called engines. While it makes more sense than aaa, having it in the middle of the core application directories was messy—especially when you expanded a couple of core and engine directories. Now, while aaa doesn’t stand for anything, you could argue that it’s an acronym for “Auxiliary Application Addons”. 🙃 “aaa engines” is now part of Zipline’s common language. It also helps us differentiate them from other kinds of engines (e.g. engines offering capabilities such as view components, form auto-save, etc).
We leverage Rails Engines to make Rails aware of app code, routes, and migrations stored in an aaa subdirectory. We are NOT building configurable engines, isolated from the rest of the app, that get mounted at a specific path, like devise or active admin.
