Backbone.js や Ember.js などの新しい JS フレームワークの使用に関する記事をいくつか読みました。
Backbone.js/Ember.js のような JS フレームワークを使用する場合、ロジックをバックエンド (Django) からフロントエンドに移動します。
したがって、Django は実際にはそのモデルのみに使用されるのでしょうか? つまり、Django Views と Django Template はもう必要なく、Django バックエンドはフロントエンドで消費される「基本的な」REST API に変わります。
同意しますか？この場合、それがDjangoの目的ですか？
フロントエンドに Backbone.js/Ember.js のようなフレームワークを使用する場合、django バックエンドを REST API に変換することは、最も適切なユースケースの 1 つですか?
ありがとう。
Django はこのように使用してもまったく問題ありません。管理者、モデル、orm、およびすべてのサードパーティ プラグインを取得できます。ただし、非常に高速ではないため、単純なドキュメント レベルの非リレーショナル REST マッピングを実行している場合は、たとえば node.js や mongoDB を調べたくない場合があります。
django に固執している場合 (私たちと同じように、django が提供する構造が気に入っています)、REST プラグインのいずれかを使用できます。
フロントエンドの開発のみを行いたい場合は、当然のことながら、すべてのバックエンドを処理するcloudmine.meやfirebase.comなどの Backend-as-a-Service の場所を有料でチェックしてください。
単一ページ ソリューションと Javascript アプリケーションについて考え始めると、Django は不要に思えるかもしれませんが、サイトを「フェイル プルーフ」にしたい場合は、サイトのクライアント側 Javascript バージョンとバックエンドの両方を開発することは不可能ではありません。ユーザーまたはサイトのJavaScriptが何らかのレベルで失敗した場合のdjango側。もちろん、これにはサイトを 2 回作成する必要があり、最新のブラウザーの時代にはおそらく必要ありませんが、完全なソリューションのために 2 つを混在させる数少ない例の 1 つです。
はい、それについてです。これを使用して、リソースなどへの認証を管理し、アプリケーションのメインビューを使用することもできますが、これらのフレームワークはjson / xml応答で機能するように作成されているため、サーバー側のテンプレートを使用する必要はありません。
そのため、多くの人がdjangoのような完全なソリューションではなく、より軽いバックエンド/バックボーンまたは残り火のコンボに移行しています。djangoを使用してjson応答をキャッシュすることもできます。これにより、アプリケーションの表示が速くなります。
私たちはそれを行っており、django-piston を使用して簡単に操作できるようにしています。
通常、Web サイト全体を Django で作成し、1 ページだけが backbone.js を使用した「単一のアプリ ページ」になります。通常、そのページは非常にインタラクティブなページであり、頻繁に発生する小さな更新が多数あり、非常に高速に表示する必要があります。ユーザー。このページは、多数の変更とユーザー インタラクションがクライアント側で構築されているため、サーバーではなく PC リソースを使用しています。残りのページでは、非常に安定した安全な環境を提供するため、django を使用できます。サーバー側のフレームワーク