Rails engines overview
Rails engines are Rails applications that can live inside another one. This course reads that pattern in gems an app already depends on: Turbo, Stimulus, Tailwind, Active Storage, Action Mailbox and Action Text. It covers isolate_namespace and what it isolates, engines with and without routes, the mount keyword, and the full versus mountable distinction. It also compares hand-written table naming with engine isolation, discusses when domain modules can stay plain namespaces, and traces one Active Storage request through an engine.
What you'll learn
- ✓Spotting which gems in a dependency tree are Rails engines
- ✓What isolate_namespace isolates and what stays shared
- ✓How engines add routes with or without a mount call
- ✓The difference between full and mountable engines
- ✓When plain Ruby namespacing is enough and when an engine fits
Thirteen engines already running in this app
The search matches fourteen gems in this project's dependency tree. One of them, railties, only matches because it defines Rails::Engine itself, in its documentation and in the template for new plugins. The other thirteen each define a class shaped class Engine < Rails::Engine. Turbo, Stimulus,…
Read the full lesson free →Curriculum
7 lessonsThirteen engines already running in this app
Identifies thirteen engines in this app's dependency tree and defines a Rails engine as an app inside another.
isolate_namespace: what it isolates
Reads isolate_namespace in three gems and explains that it isolates names, while process and database stay shared.
Engines that add routes, and engines that don't
Shows that only Turbo, Active Storage and Action Mailbox add routes, drawn straight onto the host app's route set.
mount, and the full-versus-mountable distinction
Explains mount with the Sidekiq::Web example and how the --mountable generator option builds on --full.
Isolated tables: this app's own precedent
Reads this app's table_name_prefix convention and hand-written table names as the idea isolate_namespace automates.
When this catalog's domains are, and aren't, engines
Argues engines pay off through reuse across separate apps, so the domain modules stay plain namespaces for now.
Putting it together: tracing one request through an engine
Traces an Active Storage logo request through route, controller and model, all in one process and database.