何よりも先に、Thoughtbot のBackbone.js on Rails本を読むことをお勧めします。これは、中級者から上級者を対象としていますが、出発点としては最適です。私はこの本を購入しましたが、すでに Rails を扱っていましたが、完全な backbone.js の初心者として、非常に役に立ちました。
さらに、これらのフレームワークを組み合わせるには、この本や他の本で説明されている詳細を超えた基本的な問題がいくつかあります。以下は、RoR と backbone.js を組み合わせた私自身の経験から、考えてみることをお勧めします。これは長い回答であり、質問の詳細から少し外れていますが、直面している問題を理解するという「全体像」の意味で役立つことを願っています.
Rails: Web フレームワークと API
Rails アプリケーションの上で backbone.js を使用するときに最初に直面するのは、ビューをどうするかということですが、これは実際には、より深い問題の表面にすぎません。この問題は、RESTful Web サービスを作成することが何を意味するかという、まさに核心に迫るものです。
routes.rb
Rails は、標準の HTTP アクションを介して (ファイルで定義された) 均一な URI でアクセスされる一連のリソースに関してルーティングを構造化することにより、ユーザーが RESTful サービスを作成することを奨励するように、すぐにセットアップできます。したがって、Post
モデルがある場合は、次のことができます。
GET
にリクエストを送信して、すべての投稿を取得します /posts
GET
にリクエストを送信/posts/new
し、フォームに記入して (POST
リクエスト) を に送信して、新しい投稿を作成します。/posts
- にリクエストを送信し、フォームに記入して (リクエスト) を に送信
123
することにより、id で投稿を更新しますGET
/posts/123/edit
PUT
posts/123
- にリクエストを
123
送信して、id の投稿を破棄しますDELETE
/posts/123
Rails のこの側面について覚えておくべき重要なことは、Rails が基本的にステートレスであるということです。これまで何をしていたかに関係なく、有効なフォーム データを含むリクエストを正しい URI にPost
送信するだけで、新しい を作成できます。もちろん、注意点があります: ログインする必要があるかもしれません (私を識別するセッション Cookie を持っています) が、本質的に、Rails は私がリクエストを送信する前に私が何をしていたかをあまり気にしません。別の投稿を更新するか、利用可能な他のリソースに有効なアクションを送信することで、フォローアップできます。POST
/posts
Rails の設計方法のこの側面により、(Javascript を使用しない) Rails Web アプリケーションを API に変換することが比較的簡単になります。リソースは類似または同じであり、Web フレームワークは HTML ページを返し、API は (通常) データを返します。 JSON または XML 形式。
Backbone.js: 新しいステートフル レイヤー
バックボーンも RESTful リソースに基づいています。backbone.js モデルを作成、更新、または破棄するときは常に、上記の種類の RESTful アーキテクチャを想定した URI に送信される標準の HTTP アクションを介して行います。これにより、RoR などの RESTful サービスとの統合に最適です。
しかし、ここで強調すべき微妙な点があります。backbone.jsは API としてRails とシームレスに統合されます。つまり、HTML ビューを取り除き、 RESTful リソースの提供、データベースとの統合、セッション管理の実行などにRailsを使用すると、backbone.js がクライアント側に提供する構造と非常にうまく統合されます。コード。このようにレールを使用することは何も悪いことではないと多くの人が主張していますが、私は多くの点でそれらが正しいと思います。
ただし、Rails のもう 1 つの部分 (ビューとビューが表すもの) をどうするかという問題から複雑さが生じます。
ステートフルな人間、ステートレスなマシン
これは実際には、最初に思われるよりも重要です。HTML ビューは、サービスが提供する RESTful リソースにアクセスするために人間が使用するステートレス インターフェイスを表します。それらを廃止すると、2 つのアクセス ポイントが残ります。
- 人間の場合: backbone.js レイヤー (ステートフル) によって提供されるリッチなクライアント側インターフェース
- マシンの場合: Rails レイヤーによって提供されるリソース指向の RESTful API (ステートレス)
人間用のステートレス (RESTful) インターフェースがなくなったことに注意してください。対照的に、API を使用する従来の Rails アプリでは、これに近いものがありました。
- 人間用 HTML リソース (ステートレス)
- マシン用の JSON/XML リソース (API) (ステートレス)
リソースにアクセスするための後者の 2 つのインターフェースは、前の 2 つよりも本質的に互いに近いものです。たとえば、Rails のRespond_withを考えてみてください。これは、類似性を利用して、さまざまな RESTful レスポンダーを統一された方法でラップします。
一緒に働いている
これはすべて非常に抽象的で、的外れに思えるかもしれません。より具体的にするために、次の問題を考えてみましょう。この問題は、rails と backbone.js を連携させることについての質問に戻ります。この問題では、次のことを行います。
- JSON 形式でリソースを提供するバックエンドとして rails を使用し、backbone.js を使用してクライアント側のリッチなエクスペリエンスを備えた Web サービスを作成します。
- アプリ内の各ページに、(ブラウザ バーに入力して) 直接アクセスできる
pushState
URL (例: ) を指定するために使用します。/posts/123
- これらの URL ごとに、javascript を使用しないクライアント用の HTML ページも提供します。
これらは最新の Web サービスにとって珍しい要求ではありませんが、複雑な課題を生み出します。簡単に言うと、2 つの「人間向け」レイヤーを作成する必要があります。
- ステートフルなクライアント側インターフェース (backbone.js テンプレートとビュー)
- ステートレス HTML リソース (Rails HTML ビュー)
これを実際に行うことの複雑さから、最近では多くの人がこれら 2 つのうち後者を放棄し、リッチなクライアント側インターフェースを提供するだけになっています。何を行うかは、目標と達成したい内容によって異なりますが、この問題について慎重に検討する価値があります。
それを行うための別の参考資料として、O'Reilly のRESTful Web Servicesを参照することをお勧めします。Rails と Backbone.js に関する質問で REST に関する本を勧めるのは奇妙に思えるかもしれませんが、実際には、これはこれらの非常に異なるフレームワークを組み合わせる重要な部分であり、それをより完全に理解することは、REST を活用するのに役立ちます。両方の強み。