Rails for Everything - すべてのための Rails の力

• Rails 8は 小規模プロジェクトや1人開発者に非常に有用
• 最新の入門ガイドで本番レベルのアプリを簡単に構築できる
• SQLiteの改善により、追加サーバーなしで堅牢なデータベース環境を構築できる
• デフォルトで提供される継続的インテグレーション（CI）と認証ジェネレータにより、開発効率とセキュリティを高められる
• Kamalによる手軽なデプロイ方式で、迅速かつ安全にサービスを運用できる

---

概要

• Rails 8 の活用体験を踏まえると、小規模プロジェクトや個人開発者向けの優れた Web フレームワークである
• 迅速な構築、効率的なデプロイ、組み込みモジュールなどにより、競合フレームワークと比べて生産性面の優位性が際立つ

最新ガイドの優位性

• 最新のGetting Started with Railsガイドは、初心者でも本番アプリを作成できる構成になっている
• Ruby のインストール手順は依然として複雑だが、ガイドの説明に従えば、認証、キャッシュ、リッチテキスト、継続的インテグレーション、データベースがすべて適用された堅牢なサービスを構築できる
• 単なる“Hello World”ではなく、実際のサービスレベルでの基本と機能提供を備えることが強みである
• Rails に慣れていない初心者にとって最適なスタートポイントとなる

SQLite だけで十分

• SQLite は本来優れたツールだが、これまで本番環境で使うには簡単に構成しにくかった
• 以前は追加の Gemインストールなどの追加作業が必要だったが、Rails 8では追加作業なしで本番環境で安定的に使える
• PostgreSQL や別サーバーを起動する必要がなく、solid cacheを使えば Redis サーバーも不要
• RailsとSQLiteだけでサービス運用が可能で、構築と運用のシンプルさとコスト効率を最大化できる

簡単な継続的インテグレーション（CI）

• 初回コミット後に継続的インテグレーション（CI）失敗通知が届くほど、Rails 8 では標準で統合された CI 設定が提供される
• 追加作業なしで GitHub Actions と連携でき、毎月2,000分の無料実行時間を利用できる
• 1人開発者にとってはかなり十分な時間量である

認証ジェネレータの導入

• 既存の Devise のような認証 Gem は強力だが、構成の複雑さのため初心者にはやや難しく感じられていた
• Rails 8 ではシンプルな認証ジェネレータが追加され、コンソールから既存ユーザーを追加するだけで簡単にログインフローを実装できる
• 生成されたコードはシンプルで読みやすいため、初心者でも理解しやすい

Kamal を使った簡単で高速なデプロイ

• デプロイ工程はKamalが担い、deploy.yml ファイルの一部を修正し、案内通りに進めればすぐに SSL 環境でアプリを起動できる
• GitHub Pages に SSL を接続することよりも、より高速なウェブアプリのデプロイ体験である
• 継続的インテグレーション（CI）と簡単なデプロイの組み合わせは、Rails 8 の長所の中でも特に際立つ点である
• 入門ガイドをたどるだけで、最新のベストプラクティスに沿った開発体験を可能にする

結論

• Rails は依然として強力で進化し続けるフレームワークである
• 今年新規プロジェクトを検討するなら、Rails 8 で開発に挑戦する価値がある

[aer0700]

最近はSQLiteの記事をよく目にするようになってきて、いよいよSQLiteが「全部」まできてしまいましたね。 これを古典の再ブームと言うべきでしょうか？

[GN⁺]

Hacker News の意見

• 最近 Spring Boot や Micronaut スタックでアプリを作り、React フロントエンドまで触っている。Rails の omakase（全部入り）方式がとてもありがたい。バックエンド側の フォームバリデーション や flash メッセージのような単純な機能まで、フレームワークが直接解決してくれず、自分で実装したりサードパーティを探したりする必要がある。Rails はウェブアプリの 90% がぶつかる課題を先回りして解決してくれる。完璧とは言えないが、ほとんどの場合デフォルト機能だけで十分で、必要ならいつでも置き換えられる。
  • Spring Boot は フォームバリデーション がほぼ標準で提供され、アノテーションを使えばすぐに使える。
• Rails と Django の両方が 素晴らしいフレームワーク だと思う。Python でミッションクリティカルなアプリも作ってきた。しかし、規模の大きい モノリス 開発は Go へ移りたい気持ちがある。Go の型システムと 並行性 がより強力だと感じるからだ。問題は、Go 側が Rails や Django のような フレームワークエコシステムを作る力を持っていないこと。Go で ネットワークツール や CLI を作るときは最高だが、フルスタックの Web アプリを素早く作るには、今も Rails や Django を選ぶ。だから「Rails の終わりだ」という声にはあまり共感できない。
  • ogen のようなツールのおかげで、1 つの OpenAPI 文書から静的ルーター、リクエスト/レスポンス検証、Prometheus モニタリング、OpenTelemetry トレースなど、ほとんどすべての機能を自動生成できる。クライアントと Webhook コード生成も可能で、認証は機能を1つ追加すれば済む。sqlc と SQLite の pragma user_version を組み合わせれば、型安全な DB コードとマイグレーションも簡単だ。SQLite の追加も main.go に import を2行書けば終わる。Go の標準テンプレートだけでフロントエンドのテキスト処理は十分でき、embed で静的アセットもバイナリに簡単に含められる。デプロイも go build してバイナリを移動するだけなので、デプロイが非常に簡単になった。コード生成ツールのおかげで、Go バックエンド開発はとても速くて簡単になっている。
  • 私も 静的型 完備スタックを求めていたが、Go や Rust というより明確に ASP.NET が答えだった。Microsoft が新製品（例えば Aspire.NET）をよく宣伝しているが、むしろ .NET Core（C#、ASP.NET Minimal API/MVC、EF Core）のほうが本当にバッテリー同梱で信頼性も高い。少し OOP と DI へのマインドセットの転換は必要だが、経験豊富な開発者にとっては大きな問題ではない。
  • Go エコシステムの問題は アンチフレームワーク な考え方だけでなく アンチモダン機能 的な考え方もある。Java、Kotlin、Scala、C#、F# などもネットワークツールや CLI 開発には向いている。最近は Java AOT も商用ライセンスの心配がなく、.NET も Windows に縛られていない。
  • Encore を勧めたい。特に PaaS 連携時は（NextJS+Vercel 組み合わせのように）とても強力だ。Go のコア原則とは少し違うだろうが、小規模チームや1人チームにはかなり良い選択。必要なら BYOC で直接デプロイするか、stdlib で直接 API レイヤーを立てても問題ない。フロントエンドは NextJS や Remix/RR7 が必要だが、TypeScript クライアント SDK の自動生成で統合はとても簡単。Encore は Vercel PR 連携もあるので、その点も大きな強み。
  • Go で Django のような体験を与えられるのは beego くらいがまともだ。とはいえ、まだ十分に 成熟 しておらず、Django や Rails クラスと呼ぶには早い。
  • 今 Go で進めているプロジェクトで、かなり きれいなコードに満足感を覚える。AI がフレームワークの参入障壁を越えるのに大きな助けとなっている。それでも顧客向けサービスは Rails、社内ツールやデータ作業は django のほうが直感的だという考え。
  • Ruby でも Sorbet を使えば型チェックは可能で、Fiber でサポートされる並行性機能はほぼ完成段階にある。Falcon という新しい Web サーバーが Fiber で構築されている。まだ Puma ほどではないが、近いうちに本格利用が可能になるだろう。
  • Stanza 言語の著者が、Rails のような強力なフレームワークのためには言語自体に条件が必要だという示唆を示す記事を書いている。Go や Java でそのようなフレームワークがないのは、言語の限界（またはプログラマの限界）が複合的に働いた結果だ。
  • Go はもともとその種（Rails/Django のような）フルスタック指向ではなかった。
  • Node/Express はローカル開発者向けのピコサービスレベルに適していて、ASP.NET WebAPI/MVC は私には理想的なバックエンドだ。
  • goravel dev も一度使ってみる価値がある。
• Rails Guides を最初から最後まで追うと、認証、キャッシュ、リッチテキスト、CI、DB まで含む 本物のサービスをすぐにリリースできる。しかし GitHub や Airbnb のような巨大サービスには向いていても、初期スタートアップでは Devise 認証、turbo、テストなどの追加/内蔵機能を最初から全部入れると、逆に時間の無駄になりうる。turbo はページロードが速くなる利点があるが、devise と衝突して開発時間が増えることもある。公開前のアイデア検証段階なら、銀行・医療アプリではない限りテストや CI などは保留しても大きな問題はない。デフォルト・バイアス（あるから使う）に惑わされず、不要なものは「今は使わない」と自信を持って断ることが重要だ。
  • SaaS アプリを考えるなら、Jumpstart Pro や Bullet Train のような Rails 専門のテンプレートから始めると、数ヶ月分の開発時間を削減できる。最初から決済、認証などの基本機能が入っていて、後での拡張も簡単だ。
  • テストに対する立場には賛同しない。かなり小さなアプリでも テストコード があればむしろ時間が節約できる。CI も通常は20行ほどのファイル1つで済むので、以前のプロジェクトでコピペして使っていた。
  • CI は開発速度を 短縮する要素 だ。プロジェクト初期に必ず追加しておいたほうがよい。
  • Flask/Express/Sinatra/Gradio/Hono などから Rails への移行ポイント がいつになるのか知りたい。
• 最新の Rails は以前より本当に キラキラ して見えて嬉しい。Rails 2.3 のころから12年間、さまざまなアプリを保守してきたが、今の Rails は以前とは全く異なる 進化型ポケモン のように見える。Rails Upgrade Guide が非常に整理されているため、大規模なリファクタリングなしで一気に追従しながらアップグレードできた。後方互換ではないが、変化が 明確に文書化 されている点が大きな利点。ActiveStorage によりファイル添付も大きく進歩しており、Webpacker への移行で少し苦労したものの、Import Maps 機能のおかけで今はもっと簡単になったようだ。今後は 8.1 にアップグレードする予定だ。
  • 4年前、予算が少ない顧客向けに pay-cut まで許容して古い Rails アプリの保守を選んだ（Ruby 2.3 の頃）。結果として アップグレードや機能追加が本当に簡単 で、かなり満足している。
• オープンソース Rails プロジェクトを一人で開発して 月12万ユーザー を支えるようになり、上の記事に大いに共感している。もう一つ言えるのは、ActiveStorage の添付ファイル機能が本当に素晴らしいこと。デプロイは主に Dokku を使ってきたが、Kamal を試してみるのが楽しみだ。Rails は進化を続けており、Ruby もどんどん速くなっている。
  • Dokku が好きなら Cloud Native Buildpacks を試したことがあるか気になる。これで直接 OCI イメージ を作成できる。
• Ruby を学ぶには Web 開発の比重が大きくなかったので、主に知られていたのは Django のみ だった。2 つのフレームワークの違いがどこにあるか知りたい。
  • 両エコシステムとも長く触れている（最近は Rails をあまりやっていないが）。Django は Python、Rails は Ruby/Gem に結びついているので、エコシステムの影響が大きい。Django admin CMS は Rails より明らかに強力で、多くの組織が内部 CMS も全部 django で作っている。Rails はすごく スキャフォールド CLI があり、CRUD 機能を作るのが本当に早い。Rails は Django より 抽象化レベル が高く、構造やアーキテクチャが Rails 側でほぼ決めてくれるため、Django では自分で選ぶことがずっと多い。DRY と重複コード抑制には Rails のほうが熱心だ。Pythonic な直感を重視する側は Rails のマジックを重荷に感じることもあり、Rails 側は Python の反復が荒々しく見えることもある。根本的には二人のスタイルは異なる。
  • 私が consumer facing な Web アプリを作るならまず Rails を選ぶ。scaffolding と市場投入までが簡単だからだ（実際の大規模サービス経験はない）。内部ツール、データ業務、地理情報系なら Python/Django が良い。
  • 最大の違いは Python vs Ruby。Python エコシステムは非常に大きく、Django には認証と 内蔵 admin 機能がある。
  • テスト環境 では Rails の方が良いと思う。Rails は CI 設定とテストコード自動生成が一緒に提供される。
  • Django Admin は経験上、ruby 側の代替よりずっと柔軟で使いやすい と感じる。一方、テストとルーティングは Rails のほうがよく、慣例も強い。私は ActiveRecord+arel のほうが Django ORM より気に入っている（個人的には Ruby でコードを書くほうが Python より楽しい）。
  • Ruby の学習はそれほど難しくなく、Rails は Django よりもはるかに多くの 構造と規約 を前提で提供する。
• 多くの人が Rails に対してほぼ 恋愛感情に近い執着 を持っているが、私はそこまでは感じず、羨ましくなることがある。どの言語・フレームワークにもファンはいるが、Rails 側の熱は少し特別だ。
  • Rails の 慣例 に不満を感じる点も多いが、JavaScript バックエンドで同等の生産性を出そうとするとほとんど不可能に感じる。一方で逆に Rails コードを任されると、不要な理由で Rails の標準機能（例: Active Job）を再実装しているケースをしばしば見る。慣例に従った方がいつも効率的だ。
• SQLite を本番で使うと、最終的にマイグレーションで苦労する。例えば既存カラムに NOT NULL 制約を追加するには、一時テーブルでテーブル全体を書き換える必要がある。
  • SQLite には ADD CONSTRAINT などもなく、PL 言語や簡単なストアドプロシージャもサポートされないため、結局ずっと ホスト言語でラウンドトリップ していることになり、静的型言語では特に面倒だ。
  • Postgres が最高だと思うので、簡単には諦められないだろう。それでも Rails で sqlite3 が ファーストクラスの選択肢 に入ったのは前進的だ。
  • Rails のデフォルト推奨は sqlite が redis の代替という意見もあるが、実際には小さなサービス開始向けに過ぎない。後で別 DB に移行するなら sqlite で始めるのは勧めない。マイグレーション が常に苦痛だからだ。
  • Rails では ActiveRecord validation でほとんど管理できるが、根本的な制約条件の反映には限界がある。
• Ruby のインストールガイドはちょっと 複雑 だ。15 年ぶりに jekyll ブログを構築したところ、gem の使用などで苦労した。もちろん自分の落ち度もあるが、もう少し扱いやすければよかったと感じた。それでも Ruby を再び試してみたくなるきっかけにはなった。
  • セットアップは誰にとっても 簡単であるべき と考える。Jekyll はすぐに使いこなせたが、それはすでに自分の環境に Ruby と RubyGems が入っていたからだ。
• SQLite だけ使うなら litestack も一度参考にする価値がある。まだ実際には使ったことがないが、個人プロジェクトを postgres から litestack に切り替える予定。ベンチマーク性能 がとても印象的だ。
  • Rails 8 で SQLite が大きく強化されたが、本当に litestack が必要かは疑問。どんな 差別化ポイント があるのか知りたい。