Challenge 2: Map Express's Structure Onto Rails — Solution

src/controllers/  →  app/controllers/
    Both hold the thin layer that receives a request and decides what to
    do with it. Rails' version also handles rendering a view directly
    (via convention), where Express's controller functions call res.json
    or res.render explicitly.

src/models/       →  app/models/
    Both represent data. Rails' models are Active Record classes with the
    ORM (migrations, associations, validations) built in; Express's
    models/ in the reviewed example were plain classes wrapping manual
    mysql2 queries.

src/routes/       →  config/routes.rb
    Both wire URLs to handler code. Express spread this across multiple
    router files, manually mounted together in src/routes/v1/index.js.
    Rails centralizes it into a single config/routes.rb file, and a
    single resources line (covered next chapter) can replace what would
    be several individual Express route definitions.

src/services/     →  NO DIRECT RAILS EQUIVALENT
    Express's reviewed structure introduced a services/ layer specifically
    to keep business logic out of controllers and models. Rails has no
    built-in folder for this — the traditional Rails convention is to put
    that logic directly in the model ("fat models, skinny controllers").
    A dedicated app/services/ folder is a common pattern many real Rails
    apps add themselves, but it's an addon, not something rails new
    creates or assumes.

=begin
Notes:
- The services/ gap is the most important thing to notice here: it's not
  that Rails does the same thing differently, it's that Rails simply
  doesn't have an opinion on this particular layer at all, unlike
  controllers/models/routes where it has a strong, enforced convention.
- This distinction matters in later chapters (validations, callbacks) that
  cover where Rails expects business logic to actually live by default.
=end