# Rails

分類：言語
公式：https://rubyonrails.org/

言語別の既定：§2-3（/s/2.md）
Railsの標準構成（「Rails omakase」）にできるだけ乗る。外部依存を増やさないことが最大のメリットになる。

## 選ぶ場面（§2-10）
- DBの読み書きと業務ロジックが中心：ボトルネックはDB。言語の性能差はほぼ効かないので、開発速度とチームで選ぶ

## 既定として使う役割
- 認証（§2-3）：Railsの認証ジェネレータ
  - 代替 Devise：OAuth連携・多要素認証など機能を一式揃えたいとき
  - 代替 Rodauth：高度なセキュリティ要件
- CRUD中心のWebアプリ・管理画面（§2-9）：Rails（画面の多い業務システムを最も速く作れる）
  - 代替 TypeScript：外部API連携が中心、またはReactで画面を作り込みたいとき
  - 代替 Kotlin：業務ルールが非常に複雑で、既存のJava資産と連携するとき
- Rails（§6）：Railsの認証ジェネレータ（§2-3参照）
  - 代替 Devise：OAuth連携・多要素認証など機能を一式揃えたいとき（§2-3）

## 採用の根拠（§22-2）
CRUD中心のアプリで開発速度が非常に高い。近年のRailsはSolid Queue／Solid Cache／Solid Cableでジョブ・キャッシュ・WebSocketをDBだけで動かせるため、Redisなどの追加ミドルウェアが不要。GitHubやShopifyが大規模に運用している実績がある。Kamalで特定のPaaSに依存せずデプロイできる
懸念と回答：「Rubyは下火では」→ 採用企業は安定して存在し、フレームワークは毎年活発に更新されている

## 成長したときの移行（§24）→ PostgreSQL
- きっかけ：複数台構成にしたい、書き込み待ちが目立つ
- 最初からの備え：SQLite固有の書き方を避け、ActiveRecordの範囲で書く

## ケース別の構成（§19）
- 業務システム・社内ツール（Rails構成）：アプリ＝Rails＋Hotwire＋tailwindcss-rails＋ViewComponent
- 業務システム・社内ツール（Rails構成）：認証＝Railsの認証ジェネレータ（社内ならGoogle／Entra IDのSSO）
- 個人開発・MVP：Railsワンマン＝Rails＋SQLite＋Kamal＋VPS