つの方法は、Webアプリケーション開発のためのサーバ側オブジェクトとの通信

Question

背景

私の背景には、C++での組み込みデバイスとデスクトップの高いスケールのオブジェクト指向のミドルウェアとアプリケーションの開発です。今我々は私たちのスタートアップのために大規模なWebアプリケーションを作成する必要があります。

---

質問

要求 - 応答ベースと連続ポーリングベースの現在のWeb開発フレームワークは非効率的な、非常に原始的に見えます。

私は完全にサーバー側のオブジェクト指向とイベントベースのプログラミングを探しています。ここ は、このオブジェクトの

方法、このオブジェクトの

empList getAllEmployeeList(); 
empList getEmployeeOfDepartment(string strDept); 
/*Some more */ 

イベント

、それは、サーバー上のemployeeManagerという名前の永続オブジェクトが

がある例です。

employeeAdded(empID); 
employeeEdited(empID); 
employeeRemoved(empID); 
/*Some more */ 

これで、クライアント側のjavascriptはこの（サーバー側）オブジェクトのメソッドを呼び出すことができ、このオブジェクトのイベントを受け取ることができるはずです。非同期モードでメソッド呼び出しの結果を得ることができます。フレームワークはまた、view（またはhtml-jsページ）が必要なサーバーサイドイベントに登録できるようにする方法を提供する必要があります。

この方法論で動作するフレームワークはありますか？ socketIOの上にあるこのようなものは何ですか？クライアントのjavascriptとサーバサイドオブジェクトの間に良好な双方向RPCを提供するフレームワークですか？

Answer 1

は、次のコンボを試してみてください。

私は欠けている部分は、サーバー側とクライアント側の両方で使用できる構造のようなモデルだと思います。モデルは、サーバーとクライアントの間で状態を同期させる必要があります。

私は非常に興味深い記事を紹介していますが、説明したテクニックを使用できますか？

記事：

http://blog.andyet.com/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/

Answer 2

NodeJSおよびsockets.io。これらは、望ましい効果を達成するのに役立ちます。想像力の

ノード+ socket.io + Backbone.Model +ビット：

Answer 3

Meteorが水平にスケーラブルなアプリケーションのために配向されているデータベースのためのWebSocket通信やMongoDBのためsock.jsを使用Node.jsのベースのフレームワークです。 Meteorは、クライアントとサーバーの同期に関しては、大変な作業をします。データベース同期のためのコードを書く必要はありません。その結果、req/respオーバーヘッドではなく、主にアプリケーションのロジックを持つ最小限のコードベースが得られます。ここで例を見ることができます：http://meteor.com/examples/leaderboard

Answer 4

C++に詳しいなら、G-WANをチェックしてみてください。彼らにはCometを使った素晴らしい例があります（あなたが探しているもの）、またNode.JSラッパーもあります。

G-WANでは、必要な言語で書かれたクライアントサイドアプレットも使用できます。だから、あなたのために、C++は、あなたが探しているものかもしれません。

これは非常にスケーラブルなWebアプリケーションサーバーです。私が見たすべてのベンチマークから、Node.JSは高並列性ではうまくスケールされません（私は間違っているかもしれません、私に教えてください、私に情報を提供してください）。言われているように、私はあなたがやっていることと非常によく似たことをしてきました。私がしなければならなかったのは、JSから私がその時点で使っていた言語（PHP、MivaScript、SMT、Cで作ったもの）に翻訳するための非常に簡単なラッパーを書くことでした。

しかし、キー（私にとって）は、サーバーの不要なポーリングを減らすために、Cometを使用していました。

Answer 5

クロスランゲージRPCが必要な場合は、Apache Thriftが便利です。私はJavascriptクライアントがあると信じています（ただしこれを使ったことはありません）。多くの人が指摘しているように、Socket.IOの上にRPCフレームワークを構築することはできますが、猫のように牛のように絵を描くような感じです。既に存在しているか、いくつかの従来の制約がありますが、そうでない場合には、RPCが実際に使用したいモデルであるかどうか考えるのに少し時間がかかります。 RPCは漏洩してネットワーク遅延の存在を抽象化しているため、アプリの基盤にはいくつか不安な前提があります。読む価値があるかもしれないかなり短くて可読なcritique of RPCが（ASTによって）一般にある。