Backboneのようなフレームワークの使用[終了]

現在、http：//proctors.org/tvのページがあります。このページは、多数のjQueryとハッキングされたJavaScriptスパゲッティを含むいくつかのビューと添付ファイルによって駆動され、クリーンアップしたいと思います。新しいJavascript「MVC」フレームワークはテンプレートを使用し、jQueryの場合のようにすべてのデータを厳密にDOMに保存しないことを理解しています。

バックボーンを前面にして、サービスやビューなどをバックエンドとして使用すると思います。

Backboneの Doプロジェクトがあり、DrupalCon DenverでBoFまたはSessionがあったことを覚えています...

新しいフレームワークでこれを書き直したり、ここにあるものをクリーンアップするだけの時間があるかどうかを発見したいと思っています。

私は、EmberとBackboneの両方をDrupalとともに使用しましたが、あなたが考える方法では使用しませんでした。

EmberとBackboneはどちらもWebアプリケーションを作成するための優れたツールですが、Drupalは実際にそれらと一緒に使用するのに適したツールではありません。Webアプリを構築するときに望むのは、軽くて速いものです。即座に応答する場合、ユーザーに感覚を与えることができるように高速にしたいです。あなたはそれをより良くするためにそれが軽いことを望みます。Drupalは高速ではありません-WebアプリにREST APIを提供するだけであれば、Drupalの完全なブートストラップは（他の多くのオプションと比較して）長い時間がかかります。DrupalはPHPであり、同時にRAMを大量に消費するため、同時ユーザーの数が制限されます。

だから、Drupalがこれに対して非常に悪い場合、なぜそれを使うのでしょうか？

Drupalが得意とするもの、つまりCMSにはDrupalを実際に使用する必要があります。Webアプリが必要なプロジェクトで過去に行ったことは、Drupalを使用してWebアプリの周りにCMSを作成することです。ブログ、コンテンツリストなどを作成する。また、スキーマ定義やDrupalを使用するのが理にかなっているその他のものなど、いくつかのバックエンドのものを定義するモジュールも作成しました。

Drupalを使用してwebappが必要とするREST APIを作成する代わりに、Node.jsを使用して実際のREST APIと、webappが行う必要のある他のAJAX呼び出しを作成しました。Node.jsはまさにこれを行うのに優れています。非常に高速です（オブジェクトのリストの応答時間は30ミリ秒）。また、サーバー上のJavaScriptは非同期アクションを使用するため、非常に軽量です。Node.jsサーバーは通常、PHPが100を処理できる数千の同時ユーザーを処理できます。さらに、Node.jsはJavaScriptであるため、多くの再利用が可能ですコードサーバーとクライアント側の。JavaScriptでクライアント側とPHPでサーバー側の両方を実装する代わりに、文字通り同じ検証コードを書くことができます。数週間後にミュンヘンのDrupal conに行く場合は、node.jsのプレゼンテーションを見ることを検討してください。。

あなたが開発者であれば、同様のセットアップを行うことを強くお勧めします。Drupalは本当に得意なものにのみ使用してください。単純なWebアプリケーションを作成したいが、多くのユーザーを期待していない場合、開発時間を短縮するのであれば、Drupalをバックエンドとして使用することも選択肢の1つです。

Drupal 8を更新する

そのため、Drupal 8のリリースでは、上記のいくつかはまだ当てはまりますが、以前と同じ拡張ではありません。Drupal 8は、Node.js、Rails、Djangoなどの軽量ツールではなく、Drupal 7のようなものです。JavaScriptアプリは主にさまざまなサービスを消費するため、Drupalが最適なツールであるかどうかを検討する必要があります。

Drupal 8では、多くのことが改善されました。サービスははるかにネイティブで、Symphonyが要求/応答を駆動します。Drupal 8には、高度なキャッシングとすべての優れた機能により、多くの興味深い可能性があります。しかし、Drupal 8の優れた機能をすべて備えているにもかかわらず、軽量アプリケーションよりもはるかに重いです。Drupal 8が高速Webサービスプロバイダーとしてどのように使用できるかを知るのは困難です。

だから、すべてが言われ、行われたとしても、私の一般的な推奨事項は変わりません。Drupalの開発者であるため、Drupalを使い慣れているので、すべてにDrupalを使用するのは簡単です。それは安全だと感じており、Drupal はほぼすべての用途に使用できます。Drupalを何にでも使用することは可能ですが、それがすべてに最適なツールであることを意味するわけではありません。健全な分析を行い、ITプロジェクトで使用するツールの長所と短所を理解することは、常に大きな助けになり、期待に応えられない結果をもたらすデッドロック状態に陥ることを避けるのに役立ちます。 。

私は最近、最初のバックボーン+ drupalアプリケーションの開発を開始し、それを本当に楽しんでいます。サービス、サービスビュー、および必要なライブラリとともにBackboneモジュールを使用します。プロジェクトは非常に単純です。さまざまなデータを表示する6ページのコンテンツ管理可能なカルーセルと、さまざまなコンテンツを表示する追加のニューススライダーを作成します。このページはユーザーの操作なしでさまざまな画面に表示されるため、ブラウザを更新せずにフロントエンドのコンテンツを更新する必要がありました。これは、Drupalがコンテンツを管理し、バックボーンを制御してdbと同期するDrupal + Backboneアプリに完全に適合すると思いました。私はjquery.cycle 2に統合しました。jquery.cycle2は素晴らしいAPIを備えており、MVCスタイルのコーディングによく適合しています。

Drupalをバックエンドフレームワークとして使用することになぜ人々が鼻を突き刺すのかがわかりますが、このような小さなアプリケーションの場合、Drupal は軽量で高速です。最小限のインストールから始めて、contribおよびcoreモジュールを慎重に選ぶことでこれを達成しました。私は現在、約50のモジュールで、バックボーン用に150行弱のカスタムJSコードを使用しており、ほぼ完了です。

ビューをコレクションなどとして使用する方法を示す例は現在ないため、最終的にはバックボーンモジュールの例としてこれをコミットしようとします。

結論として：

プロジェクトが適切に一致する場合は、これを検討する価値があります。私の意見では、Drupalの重さに起因するパフォーマンスの問題は、ニスのようなキャッシングメカニズム、またはブーストまたはコアページキャッシングを使用することで簡単に対処できます。Drupalを使用することによる開発の柔軟性とスピードは、私にとってのマイナス面を完全に上回ります。

基本的な答えはイエスです。一部の人々はそれを使用しています。私は自分で使用していません（まだ良いプロジェクトは見つかりませんでした）が、現在はDrupalグループがあり、Drupal 8イニシアチブの 1つであるWeb Services and Context Core Initiativeにも適合します。DrupalCon Munich 2012では、フロントエンドのBackbone.jsのセッションもあります。

まだプライムタイムの準備ができているかどうかはわかりませんが、私の意見では、それから利益を得ることができ、実装ではなくインターフェイスにJS側を設計できるかどうかの概念実証を作成する価値があります。これは、何らかの理由でDrupalを救済することにした場合に、バックエンドの変更を分離するのに役立ちます。

これは便利です。JQueryベースのスクリプトをバックボーンスクリプトに変換する例を示しています。明らかに、drupal_add_jsを使用するライブラリーとして、またはモジュールを使用して、backbone.jsをプルする必要があります。

https://github.com/kjbekkelund/writings/blob/master/published/understanding-backbone.md/