Ruby on Rails vs Hanami:プロジェクトに最適なWebフレームワークの選び方

本記事は2024年5月23日に更新され、RailsとHanamiにおけるモデルおよびデータ永続化の違いについて明確化されました。

Ruby on Railsは、Rubyエコシステムで最も人気のあるWebフレームワークであり、フリーランスから大手企業まで幅広いユーザーベースを抱えています。活発なコミュニティと充実したドキュメントを備え、シンプルなアプリケーションから複雑なWebプラットフォームまで、あらゆるものの構築に活用できます。

しかし今、そのRailsの支配的地位に挑戦する新しい存在が登場しています。それがHanamiです。Hanamiは高速でモジュール性に優れたRubyフレームワークで、Railsと比べてパフォーマンスと保守性が向上している点が特徴です。

本記事では、パフォーマンス、機能、テストなどの観点から、それぞれのフレームワークの強みと弱きを詳しく解説します。顧客向けWebアプリ、社内ツール、大規模スケーラブルなAPIなど、何を構築する予定であっても、次のプロジェクトに最適なフレームワークを選ぶための知識が得られるはずです。

まずは、それぞれのフレームワークの簡単な紹介から始めましょう。

Ruby on Railsとは

Ruby on Railsは、RubyのWebアプリケーション開発フレームワークとして最も有名な存在で、開発者の生産性向上をミッションとしています。アプリの構築方法について多くの前提を設けることでこれを実現しており、この考え方は「Rails way(Rails流)」と呼ばれています。

こうした前提には、「設定より規約(Convention over Configuration)」という思想があります。これは開発者が設定作業に時間を費やさないようにするためのものです。また、DRY(Don't Repeat Yourself:同じことを繰り返さない)原則も重視されています。DRY原則では、同じコードを何度も書くのではなく、アプリケーションの機能を単一かつ集中的に表現することで、保守性と整理された構成を実現することを推奨しています。

Hanamiとは

RailsがRubyコミュニティで広く知られている一方で、Hanamiの知名度はまだ低めです。RailsのフルスタックWebフレームワークとしての支配的な地位に挑戦する、比較的新しいモダンなRubyフレームワークです。

Hanamiは、小さなメモリフットプリントとモジュール性への重点を念頭にゼロから設計されており、その結果、非常に高速で機敏なフレームワークとなっています。

もちろん、これだけの簡単な紹介では、自分に最適なフレームワークを決めるための十分な情報にはなりません。そこで次は、それぞれの構造から掘り下げていきます。

RailsとHanamiの構造とアーキテクチャ

RailsとHanamiはどちらもRubyフレームワークである点で似ていますが、その作られ方やアプリケーションアーキテクチャには大きな違いがあります。

まず、Railsの場合、ファイル数(つまり抽象化の数。アプリ構築の building block となる要素)は少なめですが、開発が進むにつれて各ファイルが大きくなっていく傾向があります。一方、Hanamiは抽象化をまったく別のレベルに引き上げており、多数の小さなファイルで構成されるのが特徴です。

以下の図を見ると、この違いがより明確になります。まずはRailsから見てみましょう。

次に、このRailsの抽象化図を、以下のHanamiの図と比較してみてください。

ご覧のとおり、どちらのフレームワークも基本的にはモデル・ビュー・コントローラー(MVC)構造に従っています。ただし、Hanamiは抽象化をさらに一歩進めています。

各フレームワークの構成を簡略化してまとめると、以下のようになります。

• ルーティング — どちらのフレームワークにも、アプリのエンドポイントを定義するルート定義が存在します。
• コントローラー vs アクション — Railsでは、1つ以上のアクションを含むコントローラーを使用します。コントローラーはルートからのリクエストを受け取り、適切なアクションへ振り分けて応答します。一方、Hanamiにはコントローラーが存在せず、代わりに自己完結型のアクション(各アクションが独立したクラスを持つ)に直接アクセスします。
• モデルとデータ永続化 — Railsのモデル層は、データバリデーションとデータベース通信(アプリが必要とするクエリを含む)を担います。永続化はRuby Object Mapper(ROM)によって処理されます。一方、Hanamiのモデル層はより抽象度が高く、エンティティとリポジトリに分離されています。エンティティはドメインロジックを扱い、データベースに依存しない設計です。リポジトリ(repos)はデータベースとの通信に使用されます。また、Hanami 2.0以降は事前設定済みの永続化レイヤーが同梱されておらず、ニーズに合ったORM(Object Relational Mapper)を選択するか、ORMなしで開発することが可能です。
• ビューレンダリング — 永続化レイヤーと同様に、Railsのビューは外部にデータをレンダリングするために必要なものすべてを1箇所にまとめる傾向があります。HTML構造、ビューヘルパー、ビューロジックがすべて含まれます。一方、Hanamiのビューレンダリングはより抽象的です。ビューがアプリのビューヘルパーを利用し、テンプレートをレンダリングします。テンプレートは実際のHTML構造を担当し、パーツ(parts)がプレゼンテーションロジックを処理します。

では、これらは実際のアプリ開発において何を意味するのでしょうか? 抽象化の数が少ないRailsは、アプリを素早く立ち上げるのに適しており、初心者にも優しい選択肢です(後述します)。Railsを使えば堅牢なモノリシックアプリを構築できますが、スケールするにつれてコードは複雑化していきます。一方、Hanamiの複雑な構造は学習のハードルこそ高いものの、大規模にスケール可能なアプリケーションの構築を可能にし、より優れたコード整理につながります。

次に、各フレームワークのエコシステムを見ていきましょう。

エコシステムとコミュニティ

前述のとおり、RailsはHanamiよりも確立されたフレームワークです。Railsの歴史は長く、それだけ大きく成熟したコミュニティを持っています。

エコシステムとコミュニティの違いをまとめると、以下のようになります。

• ドキュメント — 何を構築しようとしているかにかかわらず、Railsを使えば質の高いドキュメントにアクセスできます。認証からデータ永続化、ビュー表示まで、アプリ構築のあらゆる部分がガイドされており、さらにサードパーティによるチュートリアルも、アプリ開発に関して想像できるほぼすべてのトピックを網羅しています。

一方、Hanami側の状況はそうではありません。比較的新しいフレームワークであるため、ドキュメントの基盤は限定的です。Hanamiチームは公式ガイドの整備に力を入れていますが、Railsのドキュメント量と比べると及ばないのが現状です。

• コミュニティ — ドキュメントと同様、ここでもRailsが明確に優位です。RailsはHanamiよりはるかに長い歴史があり、最も広く採用されてきました。初心者から上級者まで、関連するSubreddit、Slackグループ、DiscordなどでRailsコミュニティを見つけられます。対照的に、Hanamiはまだ成長途上であり、コミュニティの規模はかなり小さいです。
• Gemとライブラリ — HanamiとRailsはどちらもRubyフレームワークなので、Railsで動作するGemはHanamiでも動作すると主張できます。技術的にはそのとおりですが、専門的な機能については、Railsの方が確立されたGemやライブラリの基盤を持っていることが多いです。

とはいえ、Hanamiは抽象化と特化に重点を置いているため、Railsアプリを次のレベルに引き上げられる高度なGemもいくつか持っています。たとえば、Hanamiのデフォルトであるdry-rb系のGemをRailsアプリで使えば、より良いコード整理と抽象化をもたらすことができます。

続いて、各フレームワークの学習曲線と採用状況を比較してみましょう。

使いやすさ、業界での採用、ガバナンス、学習曲線

前セクションで述べた理由から、使いやすさ、業界での採用状況、学習曲線の面では、Ruby on RailsがHanamiを容易に上回ります。具体的には以下のとおりです。

• 学習 — まったくの初心者が新しいプログラミング言語を学ぼうとする場合、最初にオンラインの学習リソースを調べるでしょう。アプリ構築のプロセスを最初から最後までカバーする学習教材が広く入手できれば、他の言語ではなくその言語を選択する可能性が高くなります。Railsはより確立されたドキュメント基盤を持っているため、初心者向けフレームワークとしてはHanamiを凌駕します。さらに、Railsは内部で多くの規約を自動的に適用してくれるため(Hanamiのような抽象的なアプローチと比べて)、初心者が習得しやすいのも大きな利点です。Hanamiの抽象化は、経験豊富なRails開発者にとっても難しく感じられることがあります。
• 業界での採用 — Python、React、C#など、他の人気があり確立されたフレームワークの採用状況は脇に置いて、Rubyフレームワークの採用状況だけで見れば、RailsはHanamiを圧倒しています。Railsの公式サイトには、このフレームワークを採用している著名な組織が多数紹介されています。一方、新参者であるHanamiはまだ広くは採用されておらず、今後変わるかどうかは様子を見るしかありません。
• 求人市場の展望 — 求人の観点では、Hanami開発者よりもRails開発者の求人が多い傾向にあります。
• ガバナンス — 見落とされがちですが、もう一つ重要な側面がガバナンスです。変化する環境はオープンソースフレームワークの進化の方向性を左右します。それ以上に、これらのフレームワークのコアチームメンバーは大きな影響力を持ち、フレームワークに何を組み込むか、どう発展させるかなどを決定づけることがあります。

良い例が、Railsの生みの親であるDavid Heinemeier Hansson(DHH)による1月の発表です。彼は今後、フルスタックのプログレッシブWebアプリケーション構築とネイティブ通知に対するファーストクラスのサポートをRailsに導入していくと述べました。これらの機能により、Railsはモバイル開発者にとって非常に魅力的なものになるでしょう。

これに対し、Rubyエコシステム外の開発者や、長年の間にRailsを離れていた開発者を含む多くの人々が、圧倒的に好意的な反応を示しました。「DHHが公約を守るなら、喜んでこのフレームワークを採用する、あるいは学び直したい」という声です。この例は、フレームワークを選ぶ際にガバナンスが非常に重要な考慮事項であることを物語っています。

ここからは視点を変えて、より技術的な話題、アプリケーションパフォーマンスについて見ていきます。

パフォーマンス:Ruby on Rails vs Hanami

開発者であれば、アプリの信頼性、応答性、そして本番環境にデプロイした後にサーバーリソースをどのように利用するかが気になるところです。これらはフレームワーク選択に大きく影響する根本的な関心事項です。

アプリのパフォーマンステストにはさまざまな手法がありますが、最も人気があるものの一つがApache JMeterです。ここではベンチマーク数値を使って、HanamiとRailsを比較してみましょう。

以下は、各フレームワークが1秒間に処理できるリクエスト数を示す簡単なベンチマークテストです。

HanamiはRailsを圧倒しており、Railsの約3倍のリクエストを処理できることがわかります。

次のスクリーンショットは、各フレームワークの平均レイテンシ値を示しています。

こちらでもHanamiが勝利し、平均レイテンシはRailsの約3分の1です。

超高速なRubyフレームワークをお探しなら(たとえば、高速かつ大規模にスケールするAPIの開発が必要な場合)、Rubyの世界でHanamiより優れた選択肢を見つけるのは困難でしょう。

テスト

コードのテストに関しては、両フレームワークとも汎用性の高いRSpecライブラリを使用できるため、非常によく似ています。

Hanamiアプリではhanami-rspec Gem経由でRSpecが提供される一方、Railsアプリで使用するにはrspec-rails Gemをインストールする必要があります。以下は、新規Hanamiアプリに最初から含まれている非常に基本的なテストスペックの例です。

$ bundle exec rspec spec/requests/root_spec.rbで実行すると、(デフォルトのビューテンプレートを編集していなければ)テストが成功するはずです。

Rails側では、いくつかの準備を自分で行う必要があります。まず、以下のようにGemfileのdevelopment/testブロックにRSpec Gemを追加し、bundleを実行します。

次に、bundle exec rails generate rspec:installコマンドでRSpecのインストールを実行し、Railsプロジェクトで使える状態にします。

最後に、テストの作成と実行の前に、Railsアプリのテストデータを定義するための別のGem「FactoryBot」をインストールしておくとよいでしょう。

テストスイートを適切にセットアップし、いくつかのテストを定義していれば、Hanamiと同じようにbundle exec rspec spec/models/user_spec.rbでテストを実行できます。結果の確認方法もHanamiアプリと同様です。

最後に、デプロイの観点から両フレームワークを比較してみましょう。

デプロイ

現在、Rubyアプリを本番環境にデプロイする方法はたくさんあります。

まず、HerokuやFlyのようなPaaS(Platform-as-a-Service)プロバイダーを利用すれば、よりシームレスな体験が得られます。DevOpsに少し挑戦して、VPS上にDocker環境を構築し、そこにアプリをデプロイする方法もあります。

どのオプションを選んでも、デプロイの手順は両フレームワークでほぼ同じだと考えてよいでしょう。唯一の注意点は、Hanamiアプリのデプロイに関する詳細なドキュメントやチュートリアルが不足していることです。

先に述べたとおり、比較的新しいフレームワークであるHanamiには、デプロイプロセスや発生しうる課題を網羅した包括的なドキュメントがまだありません。多少の試行錯行錯誤を厭わないのであれば、特に問題はないでしょう。

まとめ

本記事では、Ruby on RailsとHanamiという2つのRubyフレームワークを、機能、アーキテクチャ、パフォーマンスなどの観点から比較しました。最終的には「どちらのフレームワークを、なぜ使うべきか?」という問いに答える必要があります。以下のようにまとめられます。

• Ruby初心者であれば、まずRailsから始めましょう。習得と学習がより簡単だからです。より経験を積んだRuby開発者であれば、Hanamiのスキルセットを身につけることをおすすめします。より堅牢なRubyアプリケーションの開発に役立つはずです。
• 高速なアプリ(APIなど複数のクライアントにサービスを提供するもの)を開発する必要があるなら、Hanamiの小さなメモリフットプリント、超高速なレスポンス、低レイテンシが威力を発揮します。ただし、SaaSアイデアの検証のためのモノリシックなフルスタックアプリを開発するだけであれば、Railsの方が断然早くゴールにたどり着けるでしょう。

結局のところ、何を選ぶかはあなた次第です。両方のフレームワークのスキルを身につけておくのも悪い考えではありません。そうすれば、プロジェクトのニーズに応じて最適なフレームワークを選択できます。

それでは、Happy Coding!

P.S. Ruby Magicの記事を公開と同時にお読みになりたい方は、Ruby Magicニュースレターを購読して、記事を見逃さないようにしましょう!

P.P.S. AppSignalにはRailsとHanami両方の統合機能があることをご存じでしたか?