Ruby on Rails と Hanami:プロジェクトに適した Web フレームワークの選択

この投稿は、Rails と Hanami の間のモデルとデータの永続性の違いを明確にするために、2024 年 5 月 23 日に更新されました。

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

そうは言っても、フルスタック Ruby フレームワークのタイトルをめぐって、新しい参加者が Rails の優位性を引き継いでいます:Hanami。これは、Rails と比較してパフォーマンスと保守性が向上した高速なモジュール式 Ruby フレームワークです。

この記事では、パフォーマンス、機能、テストなどの観点から、各フレームワークの長所と短所を検討します。したがって、顧客向けのウェブ アプリ、内部ツール、または非常にスケーラブルな API のいずれを構築しようとしている場合でも、次のプロジェクトで何を使用するかについてより良い情報を得ることができるようにしておかなければなりません。

各フレームワークの簡単な紹介から始めましょう。

Ruby on Rails の紹介

Ruby on Rails は、(「Rails 方式」と呼ばれることが多い、アプリの構築方法について多くの仮定を置くことによって) 開発者の生産性を向上させるという使命を持った、最もよく知られた Ruby ウェブ アプリケーション開発フレームワークです。

これらの前提条件には、開発者が設定に時間を費やさないようにすること、または「設定よりも規約」と呼ばれるものや、DRY (「同じことを繰り返さない」) 原則の使用を重視することが含まれます。 DRY 原則は、開発者がコードを何度も繰り返すことを避け、代わりにアプリの機能を単一の焦点を絞った表現を使用して、保守性と組織性を確保することを奨励します。

お花見のご紹介

Rails は Ruby コミュニティでは非常によく知られていますが、hanami はそれほど知られていません。これは、フルスタック Web フレームワーク領域における Rails の優位性を引き継ごうとしている、かなり新しい最新の Ruby フレームワークです。

Hanami は、メモリ使用量を小さくし、モジュール性に重点を置くようにゼロから構築されており、その結果、非常に高速で機敏なフレームワークが実現します。

明らかに、これらの簡単な紹介では、最適なフレームワークを決定するために必要なすべての情報が得られるわけではありません。そのためには、それぞれがどのように構成されているかから始めて、それぞれを詳しく調べる必要があります。

レールと花見の構造とアーキテクチャ

Rails と Hanami は、どちらも Ruby フレームワークであるという点で似ています。ただし、ほとんどの違いは、それぞれの構築方法とアプリケーション アーキテクチャにあります。

まず、Rails を使用すると、 ファイルや抽象化が少なくなります。 (アプリを構築するために使用する構成要素) は、アプリを開発するにつれてサイズが大きくなる傾向があります。一方、 Hanami は抽象化をまったく新しいレベルに引き上げ、サイズが小さくなる傾向にある多数のファイルを使用します。

以下の図は、この点をより明確に示しています。 Rails から始めましょう。

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

ご覧のとおり、各フレームワークは通常、モデル ビュー コントローラーに従います。 (MVC) 構造。しかし、 Hanami は抽象化を次のレベルに引き上げます。

各フレームワークがどのように構成されているかの簡単な概要は次のとおりです。

• ルート - 各フレームワークには、アプリのエンドポイントを含むルート定義があります。
• コントローラとアクション - Rails では、1 つまたはいくつかのアクションを備えたコントローラーが得られます。コントローラーはルート リクエストを受信し、関連するアクションを指示することでそれに応答します。花見にはコントローラーがいない。代わりに、自己完結型アクションに直接進みます (各アクションには独自の自己完結型クラスがあります)。
• モデルと永続性 - Rails モデル層は、アプリが持つ可能性のあるクエリを含む、データ検証とデータベース通信を処理します。永続性は、Ruby Object Mapper (ROM) によって処理されます。 Hanami では、モデル層はより抽象的で、エンティティとリポジトリに分離されています。エンティティはドメイン ロジックを処理し、データベースに依存しないのに対し、リポジトリは (リポジトリ) はデータベースとの通信に使用されます。 Hanami 2.0 以降には、事前構成された永続化レイヤーなしで出荷されるため、ニーズに合ったオブジェクト リレーショナル マッパー (ORM) を選択したり、ORM を無料でプログラムしたりできます。
• レンダリングを表示 - 永続化レイヤーと同様に、Ruby on Rails ビューには、データを外部にレンダリングするために必要なものがすべて 1 か所に含まれる傾向があります。これには、すべての HTML 構造、ビュー ヘルパー、およびビュー ロジックが含まれます。 Hanami でのビューのレンダリングに関しては、より抽象的なものになります。まず、ビューがあります。 アプリが持つビュー ヘルパーを利用し、テンプレートもレンダリングします。 。 テンプレート 実際の HTML 構造を処理し、パーツは プレゼンテーション ロジックには注意してください。

では、アプリを構築する場合、これは何を意味するのでしょうか? Rails は抽象化が少ないため、アプリを軌道に乗せるのに適しており、より初心者に優しいものです (この記事で後ほど説明します)。 Rails を使用すると、非常に堅牢なモノリス アプリを構築できますが、規模が拡大するにつれてコードはますます複雑になります。一方、 Hanami のより複雑な構造は、学ぶのが大変かもしれませんが、非常にスケーラブルなアプリケーションを構築できるようになり、より優れたコード構成が可能になる可能性があります。

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

生態系とコミュニティ

前述したように、Rails は Hanami よりも確立されたフレームワークを持っています。 Rails は古くから存在しているため、より大規模で成熟したコミュニティがあります。

エコシステムとコミュニティの違いを以下にまとめます。

• ドキュメント - Rails を使用している場合は、何を構築しようとしているかは関係ありません。非常によくできたドキュメントにアクセスできます。認証からデータの永続化、ビューのプレゼンテーション、およびその間のすべてに至るまで、アプリのビルドのすべての部分をガイドします。さらに、サードパーティ製の幅広いチュートリアルが、アプリケーションの構築に関して考えられるほぼすべてをカバーしています。

とはいえ、花見の面では物事はそれほど確立されていません。 Hanami は比較的新しいフレームワークであるため、ドキュメント ベースは比較的限られています。 Hanami チームは公式ガイドで素晴らしい仕事をしましたが、Rails ドキュメント ベースと比較すると足元にも及びません。

• コミュニティ - ここでも、ドキュメントと同様に、Rails が明らかに勝者です。 Rails は Hanami よりもはるかに古くから存在しているため、最も多く採用されています。初心者か上級開発者かは関係なく、関連するサブレディット、Slack グループ、Discord などで Rails コミュニティを見つけることができます。一方、花見はまだ成長しており、コミュニティの規模ははるかに小さいことを意味します。
• ジェムとライブラリ - Hanami と Rails はどちらも Ruby フレームワークであるため、Rails で動作する gem は Hanami でも動作すると言えるでしょう。これは技術的には真実ですが、多くの場合、Rails にはあらゆる種類の特殊な関数用の gem とライブラリのより確立されたベースがあることがわかります。

とはいえ、 Hanami は抽象化と専門化に重点を置いているため、Rails アプリを次のレベルに引き上げる非常に高度な宝石がいくつか含まれています。たとえば、 Hanami のデフォルトの dry-rb gem は、Rails アプリで使用すると、より優れたコード構成と抽象化をもたらす可能性があります。

次に、各フレームワークの学習曲線と導入を比較してみましょう。

使いやすさ、導入、ガバナンス、学習曲線

前のセクションで説明したまさにその理由により、Ruby on Rails は、使いやすさ、業界での採用、学習曲線の点で、特に次の点で Hanami を簡単に上回ります。

• 学習 - あなたがまったくの初心者で、新しいプログラミング言語を学ぼうとしていると想像してください。まず最初に考えられるのは、オンライン学習リソースをチェックすることでしょう。フレームワークにアプリ構築プロセスの最初から最後までをカバーする広く利用可能な学習教材がある場合、他の言語ではなくその言語を選択する可能性があります。また、Rails にはより確立されたドキュメント ベースがあるため、初心者がフレームワークとして選択するものとしては Hanami よりも優れています。さらに、Rails は内部で非常に多くの仮定を行うため、(より抽象的なアプリ構築方法を提供する Hanami と比較して) 初心者にとってはるかに親しみやすいものです。 Hanami の抽象化は、確立された Rails 開発者にとっても困難を伴う可能性があります。
• 業界での採用 - Python、React、C# などの他の一般的でより確立されたフレームワークの採用を含めずに、Ruby フレームワークの採用を考慮すると、Rails は簡単に Hanami を上回ります。 Rails のホームページには、このフレームワークを使用しているいくつかの有名な組織がリストされています。一方で、花見は新参者なので、あまり広く採用されていません。将来的にそれが変わるかどうかは、様子を見て確認する必要があります。
• 雇用市場の見通し - 就職の可能性に関しては、Hanami 開発者よりも Rails 開発者の方が多くの求人を見つけることができます。
• ガバナンス - 見落とすべきもう 1 つの重要な側面はガバナンスです。変化する状況は、オープンソース フレームワークがどのように進化し、進歩するかを導きます。しかし、それ以上に、これらのフレームワークのコア チーム メンバーは多くの場合、強大な権限を行使し、フレームワークに何が含まれるか、フレームワークがどのように開発されるかなどを決定することができます。

良い例は、Rails の作成者である David Heinemeier Hansson (DHH) による 1 月の発表です。同氏は、将来的には、フルスタックのプログレッシブ Web アプリケーションとネイティブ通知を構築するための最上級のサポートを提供するよう Rails を推進すると述べました。これらの機能により、Rails はモバイル開発者にとって非常に魅力的なものになります。

これに対し、多くの開発者は、Ruby エコシステムの外にいる開発者や、長年 Rails をやめていた開発者も含めて、圧倒的に肯定的な反応を示し、DHH が約束を守ってくれれば喜んでフレームワークを手に入れるか学ぶつもりだと述べました。この例は、どのフレームワークを選択するかを決定する際に、ガバナンスが非常に重要な考慮事項であることを示しています。

ここで、気持ちを切り替えて、より技術的なアプリケーションのパフォーマンスを見てみましょう。

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

開発者は、アプリの信頼性、応答性、および運用環境にデプロイされた後のサーバー リソースの利用方法について懸念することになります。これらは、フレームワークの選択に大きな影響を与える可能性がある基本的な懸念事項です。

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

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

Hanami は、Rails が処理できるリクエストの 3 倍のリクエストを処理できる能力で、Rails を完全に上回っています。

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

繰り返しますが、 Hanami は約 3 倍短い平均レイテンシー時間で Rails を上回っています。

非常に高速な Ruby フレームワークを探している場合 (高速で非常にスケーラブルな API に取り組む必要があるとします)、Ruby 環境で Hanami より優れたものを見つけるのは難しいでしょう。

テスト

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

RSpec は hanami-rspec 経由で組み込まれます。 Hanami アプリの場合は gem を使用しますが、rspec-rails をインストールする必要があります。 gem を使用して Rails アプリで使用します。以下の例は、新しい Hanami アプリに含まれる非常に基本的なテスト仕様を示しています。

$ bundle exec rspec spec/requests/root_spec.rb で実行します 結果はテストに合格するはずです (デフォルトのビュー テンプレートを編集していないと仮定します)。

Rails 側では、いくつかのことを自分で処理する必要があります。まず、RSpec gem を Gemfile の開発/テスト ブロックに追加する必要があります。 以下に示すように、bundle を実行します。 :

次のステップは、コマンド bundle exec rails generate rspec:install を使用して RSpec インストールを実行することです。 Rails プロジェクトで使用できるように準備します。

最後に、テストを作成して実行する前に、Rails アプリのテスト データを定義する別の gem (FactoryBot) をインストールする必要がある可能性があります。

テスト スイートを適切に設定し、いくつかのテストを定義していると仮定すると、bundle exec rspec spec/models/user_spec.rb を使用して Hanami で行うのと同じようにテストを実行できます。 。 Hanami アプリと同じようにテスト結果を取得できます。

最後に、展開に関してフレームワークがどのように比較されるかを見てみましょう。

展開

現在、Ruby アプリを本番環境にデプロイするためのオプションがたくさんあります。

まず、Heraku などの Platform-as-a-Service (PaaS) プロバイダーを使用するか、よりシームレスなエクスペリエンスを実現する Fly を使用することができます。また、DevOps を少し実行することもできます。つまり、VPS 上に Docker インストールをセットアップし、そこにアプリをデプロイします。

どちらのオプションを選択しても、どちらの場合でも展開は比較的似たものになることが予想されます。唯一の注意点は、Hanami アプリをデプロイするための広範なドキュメントやチュートリアルが不足していることです。

以前に指摘したように、Hanami は新しいフレームワークであるため、展開プロセスと発生する可能性のある課題をカバーする広範なドキュメントがまだありません。これをハッキングしても構わないのであれば、大丈夫です。

まとめ

この記事では、2 つの Ruby フレームワーク (Ruby on Rails と Hanami) を取り上げ、機能、アーキテクチャ、パフォーマンスなどの観点から比較しました。最終的には、「どのフレームワークを使用する必要がありますか?その理由は何ですか?」という質問に答えなければなりません。次のように要約できます。

• 初心者の Ruby 開発者は、Rails から始めてください。Rails のほうが簡単に習得して学習できます。より高度な Ruby 開発者であれば、より堅牢な Ruby アプリケーションの開発に役立つ Hanami スキルセットを開発してください。
• 複数のクライアントにサービスを提供する API など、高速である必要があるアプリを開発する必要がある場合、hanami の小さいメモリ使用量、驚くほど高速な応答、低レイテンシーが役立ちます。ただし、SaaS アイデアを検証するためにモノリシックなフルスタック アプリを開発する必要があるだけの場合は、Rails を使用すると確実に迅速にそこに到達できます。

結局のところ、何を選択するかはあなた次第です。両方のフレームワークのスキルを習得することは悪いことではありません。そうすることで、プロジェクトのニーズに応じて最適なフレームワークを決定できます。

コーディングを楽しんでください!

追記Ruby Magic の投稿を報道後すぐに読みたい場合は、Ruby Magic ニュースレターを購読して、投稿を 1 つも見逃さないようにしてください。

追伸。 AppSignal には Rails と Hanami が統合されていることをご存知ですか?