RailsまたはSinatra：2つの世界のベスト？

年々、祝福はRubyの世界に委ねられました-Webアプリケーションを開発するためのうらやましいフレームワークがここに現れました。 ただし、最近2人がこの分野の明確なリーダーになりました。 このサイトのほとんどの読者は、 Ruby on Railsについて聞いています 。 2004年にDavid Heinemeyer Henssonによって開発され、生産性を高め、開発者を満足させるMVCフレームワークです。 2007年にBlake Miseraniによって作成されたSinatraは、ラック上の軽量HTTPリクエストおよびレスポンスのレイヤーのラッパーとして機能するドメイン固有の言語です。 彼のミニマルなアプローチは優雅でエレガントです。 RubyGems.orgの統計は、これらのフレームワークの両方がどれだけ人気があるかを明確に示しています。Railsは700万回ダウンロードされており、Sinatraは150万回ダウンロードされています。 RailsがRubyのWeb開発に私を惹きつけましたが、ここ数年でSinatraをより頻繁に使用しました（そして、ここに7つの理由があります）。 実際、アプリケーションを構築するには、Sinatraといくつかのgemだけが必要であることがわかりました。 これにより、Sinatraを使用して任意のプロジェクトをマスターできるかどうかを検討しました。 Sinatraを使用するのに最適な時期はいつですか？Railsが最適な選択はいつですか？ この質問の答えを見つけようとして、有名なRuby開発者にこれについてどう思うか尋ねました。



現在SinatraをサポートしているKonstantin Haasは、各ツールが独自の種類のアプリケーションの要件を満たしていると考えています。

それらは実際、この分野で相互作用しているという事実にもかかわらず、異なる一連の問題を解決します。 Railsはモデル指向のWebアプリケーションの作成に焦点を当てたフレームワークですが、SinatraはHTTPを処理するためのサーバー側ライブラリです。 HTTPリクエスト/レスポンスの観点から考えると、Sinatraは完璧なツールです。 完全な統合と可能な限り多くのライブラリテンプレートが必要な場合は、Railsが最適です。

また、David Heinmeier Henssonは、それぞれに場所があると考えていますが、どちらを選択するかは、アプリケーションのサイズによって決まると考えています。

Sinatraはマイクロスタイルに最適ですが、Railsはそうではありません。 最小限である限り、SinatraはRailsよりも優れています。 それを超えると、RailsはSinatraに勝ちます。

実際、ほとんどの人は、Railsが大規模プロジェクトに重点を置いていることに同意しますが、SinatraはマイクロアプリケーションとAPIに適しています。 デビッドは、RailsとSinatraの経験から得た選択規則について説明し続けます。

アプリケーションに5〜10個のエンドポイントがある場合、独自のソリューションにSinatraを使用することは有益です。 特に、コントローラー構造自体が1〜2ページのコードに収まる場合-1つのファイルで実行できる場合に最適です。

Githubの Rick Olson氏は、Sinatraが小規模プロジェクトに最適な選択肢であることを確認しています。

Sinatraは、小さなサイト（内部アプリケーション、Githubジョブなど）だけでなく、APIとしても非常に優れた機能を発揮します。

David Heinmeier Henssonが、大規模なWebアプリケーションの構築に関してRailsが非常に良い選択である理由を説明します。

Railsを使用すると、人々は最高のテクノロジー（私とRailsコミュニティは「最高」と呼んでいます）を選択できます。これは成功の大きな部分です。

Konstantin Haasは、Railsへの熱意と哲学を共有しています。

Railsが大好きです。 Railsは、Webアプリケーションのビジョンを構築しました。 Railsは、Sinatraがアプリケーションについてより多くの推測を行うことができるため、Sinatraが解決できない問題を解決します。 Railsアーキテクチャの最大の欠点は、必要かどうかに関係なく、すべてが既に設定されているため、すべてを1つのツールで解決する必要があるということです。

通常、Railsでは必要のない機会を受け取ることは間違いなく損失を伴いますが、後者はあなたが本当に必要とする多くの機会を得るという事実によって補償されます。 最終的には、特に大規模なプロジェクトに関しては、それ自体を正当化できます。 ただし、大規模なプロジェクトはRailsでしか実装できないことに全員が同意するわけではありません。 Peepcode ScreencastsのJeeprey Grozenbachは、これが「2008年のSinatraにのみ当てはまる時代遅れの外観であるが、確かに最近ではない」と考えています。 彼は、Sinatraが悪用可能な大規模サイトの作成に適していることを証明する例として、Sinatra上に構築された優れたGaug.esアプリケーションに注目しました。



上記にもかかわらず、Konstantin HaasはSinatraを使用して大規模なアプリケーションを作成する際の潜在的な問題に注意を払っています。

Sinatraでより複雑なアプリケーションを作成する（あるいは、他のアプリケーションの中でSinatraを使用する）と、開発者はアーキテクチャとツールについて考えるのにより多くの時間を費やすことになります。 これは長所でもあり短所でもあります。

一部の開発者は、アプリケーションで何が起こっているかを厳密に制御し、それがすべてどのように適合するかを理解することを好む場合、おそらくこれを利点と見なします。 ジョフリーグローゼンバッハは、これがそれを正当化する犠牲であると信じています。

安定性はシナトラの最大の利点です。 いくつかのRailsジェネレーターの利便性のために、設計上の決定を犠牲にします。 フレームワークはめったに変更されないため、Sinatraで作成すると、開発者とビジネスAPIの安定性が得られます。 コードを所有し、いつ変更するかを決定します。

彼は、シナトラがアプリケーション構築の優れた候補である理由を説明し続けています。

私の新しいアプリケーションはそれぞれSinatraで始まります。通常、SinatraといくつかのRackプラグインに加えて、フロントエンドとして小さなCouchDBライブラリとBackbone.jsは必要ないという結論に達します。

Yahooの Sow Sheong Chang氏およびRubyのインターネットアプリケーションクローニングの著者は、単純な開発モデルを持っています 。

Sinatraは基本的なプラットフォームで必要なすべてを実行し、他のすべては既にクラウドプラットフォームとサービス（Herokuとそのアドオンのエコシステムなど）で提供されているか、gemsを使用して実装できます。 そして残りは、自分でコードを書くことができます。

実際、このアイデアはSinatraのアプリケーションのより高度なアプローチとして使用できます。つまり、ニーズを完全に満たす独自の特別なフレームワークを作成します。 Sinatraから始めて、独自のフレームワークを作成するために必要な機能を実現するgemを追加します。 類似したものがPadrinoプロジェクトに実装されています。



デヴィッド・ハインマイヤー・ヘンソンはその点を見ていません：

すべてを小さな粒子に分割し、開発者に自分の手ですべてを収集させることは、Railsが作成されたすべてのものとフレームワークのゲームで勝った方法のアンチテーゼです。 私たちがこの目標を達成するために、何万もの工数が費やされました。 これを再現しようとするのは空の考えです。

アプリケーション内で行われていることを制御することは良い考えかもしれませんが、Konstantin Haaseは、これには多くの時間がかかる可能性があると警告しています。

Sinatraの主な欠点は、問題を解決しませんが、Sinatraがそれを解決しないことです。 自分で対処する必要があります。 これは、あなたがそれを解決しようとして不当に長い時間を費やすという事実につながる可能性があります。

また、開発者の予算が限られている場合、彼らはこの時間を無駄にしないかもしれません。 David Heinmeier Henssonは、Sinatraを使用して車輪を再発明しようとすると、膨大な時間を無駄にすることに悩まされます。

ほとんどの場合、Railsで既に提供されているソリューションを再現するために行う必要があるすべての作業は、Sinatraの使いやすさをすぐに消去します。 Basecamp、GitHub、Shopify、または他の大規模なアプリケーションをシナトラだけで構築しようとしている人には申し訳ありません。 Railsは、このスケールのアプリケーションの作成に携わるほとんどの人が直面するほとんどの問題に対する解決策を含んでいるため、巨大で紛らわしいツールです。 これらのソリューションをすべて手動で再作成しようとすることは、単純さではありません。

Railcastのリーダーである Ryan Batesは、Railsを使用する利点は、プロジェクトをゼロから開始するときに時間を節約できることだと考えています。

標準のRailsアプリケーションは、私が必要とするものの多くを提供し、Sinatraでの追加インストールが必要になります。 そして、これはRailsでの開発時に余分な速度を提供します。

同じ意見がRick Olsonによって表明されました。RickOlsonは、RailsがGitHubプロジェクトの実装を促進したと考えています。

最初の1年間は、Railsが[GitHub]の創設者にとって主要なツールだったと思います。 彼らはRailsの高レベルの機能のいくつかを活用し、素早く反復することができました。

Chad Fowler （RubyConfの共同設立者）は、Railsが大規模プロジェクトの開発を高速化するもう1つの理由として、「構成合意」のRailsのマントラを挙げています。

Railsのジェネレーターと構造体は、Sinatraが提供していない規則を提供します。

問題は、これらの契約が拘束に似ていることもあるということです。リックオルソンはそのような場合に注意を促します。

Railsは、その独断的な慣習が受け入れられ、「黄金の道」を順守している場合に適しています。

彼とは異なり、シナトラには制限がありません.Ruby Learningの Satish Talimは、これを説明するAron Quintからの壮大な引用を引用しました：

「シナトラは抽象的なテンプレートNNNVS（臭いテンプレートは不要）に従います。 NNNSHは、Sinatraが柔軟性を超えていることを意味し、ドメインまたはビジネスロジックの編成方法を決定しません。 明示的なフォルダー構造を持たず、デフォルトのデータベース抽象化はありません。また、それをどこでどのように適用するかについての制限もありません。

ここでSinatraが最も魅力的です。これにより、アプリケーションをどのように、またどのように構成するかを決定できます。 Sinatraを使用すると、サイズ、構造、またはワークフローが制限されないため、自由が得られます。 API、Webアプリケーションを構築するか、gemにコードをパックできます。



おそらく、デビッド・ハインマイヤー・ヘンソンもシナトラのシンプルさを愛していることに驚くかもしれません：

過去に、私はシナトラを使用し、それが本当に好きでした。 彼は完全に異なるアプローチを提供します。これは、はるかに小さな円のタスクを解決するのに最適ですが、それらを非常にうまく解決します。

それで、シナトラには、彼がRailsに移したいと思うような利点がありますか？

実際、SinatraにはRailsを別の方法で作り直したいと思うものは何もありません。

しかし、彼はまだRailsがSinatraの最もクールな機能の1つをほぼ完全にコピーしたことを認めています。

単一ファイルモードをRailsに追加したかったのですが、拒否しました。なぜ、Sinatraの優れた機能を最適化する必要があるのですか？

間違いなく、Railsには非常に多くの機会がありますが、多くの場合、必要のないものや正確に機能しないものがあります。 Rails 3では、これを可能な限り滑らかにする試みが行われました-異なる種類の機能の一部を切断することにより、Chad Fowlerが指摘するように、より軽量でより構成可能な製品になる可能性があります：

特に自由裁量でサイズを縮小する現在の能力を考慮すると、Rails自体はそれほど「重い」わけではありません。

Rails 3には、実行されているタスクに合わせてアプリケーションを調整できる多くの構成オプションが用意されています。 ゴミを処分する機会があるという事実にもかかわらず、コンスタンチン・ハースは、多くの場合、すべてをそのままにしておくのは魅力的すぎると警告し、それが膨満感につながります：

私の練習では、Railsアプリケーションはしばしば単一のモノリシックアプリケーションになります。 [Rails Abandonment]は、モジュール性、柔軟性、テスト速度、およびスケーラビリティをもたらします。 ただし、Railsアプリケーションを慎重に設計すれば、同じアーキテクチャを実現できます。実際、そうでない（これを行わない）ことは魅力的です。

David Heinmeier Henssonはこれを問題とは見なしておらず、すべての機能を使用するかどうかに関係なく、Railsはとにかく次のことを行うと考えています。

使用していないRailsコードの一部を物理的に削除しても、有用なものは得られません。 すべての機能を強制的に使用することはありません。 [Railsの多くの機能]は完全にオプションであり、気になる場合は完全に無効にすることができます。

Railsはより簡単になり、Sinatraは困難なタスクに対処できることを示しました。つまり、それらはますますインターフェース化されています。 チャド・ファウラーは、実際、SinatraとRailsの両方が幅広いプロジェクトで使用できると考えています。

実際、それらはそれぞれ反対の場合に使用できると思います。 結局、これは主観的な選択だと思います。

一般的に、誰もが「仕事に適したツールを選択する必要がある」ことに同意しますが、それらを組み合わせると、ソリューションは個人の選択に委ねられることがよくあります。 Sinatraはアーキテクチャをより細かく制御できますが、余分な労力はあなたの時間（またはクライアント、さらに重要なこと）の価値ある無駄になりますか？ ライアン・ベイツは、性格タイプと彼らが選択するフレームワークを要約します：

結局、それはあなたが好むものに依存していると信じています：軽く始めて必要に応じて追加するか、重いものから始めてから、体重を減らす必要がある場合は何かを取り除きます。

Joffrey Grozenbachは、2つのまったく異なるタイプの開発者がいることを提案しています。

Ruby開発者には大きな違いがあると思います。小さいサイズ、軽量、速度、明示性、拡張性を好む人がいます。 また、あらゆる機能を備えたフレームワークを好む人もいます。 Sinatraは前者の要求を満たし、Railsは後者の要求を満たします。 ですから、シナトラがRailsに取って代わるとは思いません。 これは、ある種の開発者が好む別の哲学であるというだけです。

ただし、それらを選択する必要はありません。 著者、Ruby SourceのメンバーであるDave Kennedyは、RailsとSinatraが一般にかなりうまく機能することを指摘しています。

開発プロセス中に2つのフレームワークが互いに補完し始めた場合、これは現在、Rails内でSinatraを集中的に実行するマルチテナントアプリケーションで作業していることを示唆しています。 Sinatraを使用すると、アプリケーションにモジュール性を追加することができました。

多くの人々は、SinatraをRails 3+アプリケーションに組み込む機能のおかげで、2つの世界が提供するものを最大限に活用できることに気付きました。 チャド・ファウラーは、どちらか一方を選択するという概念自体は無意味であると考えています。

選択についてあまり心配する必要はありません。SinatraアプリケーションをRails 3アプリケーションに埋め込むことができるため、選択が可能になります。

Joffrey Grozenbachは、これによりアプリケーションのモジュール性が向上すると考えています。

多くの人がSinatraアプリケーションをRailsアプリケーションに埋め込みます。 これはDjangoフレームワークの設計を模倣しており、（メイン）アプリケーションは多くの小さなアプリケーションで構成され、各アプリケーションはその中の特定の部分を担当します（そして多くの場合、他のアプリケーションで再利用できます）。

David Heinmeier Henssonは、これがタスクを達成するための良い方法であるとも考えています。

Rails構造内でSinatraのマイクロアプリケーションを使用することもできます。 これは、いくつかの問題を解決するためにGithubで使用されます。 素晴らしいモデル。

Rick Olsonは、このペアがGitHubでタンデムに使用される頻度を説明しています。

RackとSinatraが[Rails]と非常に緊密に統合されていることを非常に嬉しく思います。 特定の機会に合わせてRailsをカスタマイズする代わりに、リクエストをSinatraまたはRackエンドポイントにリダイレクトして、必要なことを正確に行うことができます。

Rubyエコシステムには、これら2つのフレームワークそれぞれに場所があることに誰もが同意するでしょう。 本質的に、それらは完全に連携して動作し、ある程度まで相互に多くの方法で補完します。 2つのフレームワークが最適に連携し、一般的にさまざまなニーズを満たすと考える人はかなりいるようです。 ソリューションがペアリングツールの分野にある場合、さまざまなタイプの開発者が好みを選択します。 2つのそれぞれは、それがうまくいくことだけを行い、それぞれが優れた実践の例外的な例です。 これらのツールは何度も他の言語にコピーされているので非常に優れています。 John NunemakerとGitHubは、美しく簡潔にまとめました。

それぞれに独自の場所があります。 Railsは、タスクを処理するだけの場合に最適なオプションです。 シンプルなものについては、すべてを制御し、独自のビューを維持したい場合と同様に、シナトラが最良の選択です。

コミュニティとして、私たちは非常に幸運なことに、このようなよく開発されたツール、優れたサポート、さらにはオープンソースを持っています。 RailsとSinatraは両方ともタスクのすべての面で素晴らしい仕事をしているので、それらのおかげで私たちは両方の長所を持っていると言っても安全です。



あなたはどう思いますか-あなたはそれらのそれぞれを使用しますか？ Railsの代替として独自のフレームワークを作成することを検討しましたか？ 以下にコメントを残してください。



オリジナルの記事はこちらでご覧いただけます 。