Routing: Rails' Own routes.rb DSL
Website Rebuild with Ruby on Rails
Chapter 3 · Routing: Rails' Own routes.rb DSL
Next.js infers routes purely from the filesystem. Django's urlpatterns is a plain Python list assigned at module load. Laravel's routes/web.php is explicit PHP code using a fluent, chainable API. Rails' routes.rb is explicit Ruby code too — but it leans on the language's block syntax more heavily than any of the three, in a way worth showing concretely rather than just asserting.
routes.rb as an Executed Block-Based DSL
Rails.application.routes.draw do ... end passes an entire block of route declarations to a single method call, and nested structures — namespaces, resource groups, member/collection routes — are expressed as further nested blocks inside it. Laravel's own routes file is genuinely explicit code too, using a similarly fluent style (Route::get(...)->middleware(...)->name(...)), so the real distinction isn't "explicit vs. implicit" a second time — it's that Rails leans specifically on Ruby's block syntax, a language feature PHP has no direct equivalent of, for its own nesting.
The Glob Wildcard Segment
get '*path', to: 'pages#show' uses Rails' own globbing syntax — a segment prefixed with * in the route pattern string itself — to capture every remaining path segment, slashes included, into params[:path]. No separate regex constraint is required the way Laravel's own wildcard needed one.
A Dedicated Keyword for the Homepage: root
root to: 'pages#show', defaults: { path: '' } is Rails' own dedicated DSL keyword specifically for the homepage route — not a generic get '/' call reused for the purpose, the way Laravel and Django both effectively handle their own empty-path case. It's a small thing, but it's a genuinely distinct, semantically named piece of syntax none of the three siblings have a direct equivalent for.
Order Still Matters — the Same Gotcha, Repeated Honestly
get '*path' declared before a more specific route (an admin route, for instance) would swallow it. This isn't a new Rails-specific trap; it's the same trap every one of these routing systems shares, worth repeating accurately rather than dressed up as something novel.
Four Wildcard Mechanisms, Compared Honestly
| Next.js | Django | Laravel | Rails | |
|---|---|---|---|---|
| Where it lives | The filesystem itself — [...path] | urlpatterns — <path:full_path> | routes/web.php — {path?} | routes.rb — *path |
| Needs a separate regex | No | No — the converter itself is slash-aware | Yes — ->where('path', '.*') | No — the * glob is slash-aware itself |
| Named route helper | N/A — file-based | reverse() / {% url %} | route('name') | page_path |
Hands-On Exercises
Explain what makes Rails.application.routes.draw do ... end a block-based DSL, and why this is a real but modest distinction from Laravel's own fluent Route:: calls rather than a difference in explicitness.
Explain what Rails' glob segment (*path) does, and why it needs no separate regex constraint the way Laravel's own wildcard route did.
Explain why a catch-all route like get '*path' has to be declared carefully relative to more specific routes, and name the two sibling courses that already established this same gotcha in their own frameworks.
Chapter 3 Quick Reference
Rails.application.routes.draw do ... end— a block-based DSL, not a plain data structureget '*path', to: 'pages#show'— the glob wildcard, slash-aware with no separate regex neededroot to: ..., defaults: { path: '' }— a dedicated, semantically named keyword just for the homepage- Route order still matters — the same top-to-bottom precedence gotcha already flagged for Django and Laravel
- Honesty check — named route helpers and resourceful routing are genuinely shared with Laravel, not unique to Rails
- Next chapter: Views: ERB Templates & the Rails MVC