まず第一に、NodejsはNoSQLデータベースにリバースTCPプロキシを書き込むのに最適です。すべての標準コマンドを通過させることができますが、独自の魔法でAPIを変更/拡張できます。 MongoDBがHTTPを話すようにするか、CouchDBがソケットを介してバイナリプロトコルを話すようにします。
ボードゲームのピースを保存し、プレーヤーの動きを監視するためのNoSQLソリューションの選択に関しては、RedisとCouchDBのどちらかが最適な候補だと思います。
- CouchDB。高速で信頼性が高く、多数の同時HTTP接続を処理できます。 Redisとは異なり、ドキュメントが変更されたときにメッセージをブロードキャストできるため、これはおそらく最良のオプションです。 継続的な変更API
各プレーヤーのアプリでボードの変更を監視するのが非常に簡単になります。リクエストは次のようになります：
curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000
各クライアントは、関連するドキュメントが変更されるたびに、応答の1行ごとにJSONオブジェクトを受け取ります。 （そして、一種のキープアライブとして1000msごとに空白の改行があります。）
- Redis。単純なラインベースのプロトコル（MemcacheD ++など）を使用してソケットを介して通信し、リスト、セット、ハッシュを任意の値（バイナリ値も含む）で格納できるようにします。すべてがメモリ内で発生しますが、非同期でディスクに保持されるため、非常に高速です。ただし、すでに PubSub が含まれているため、評価する必要があります。 通知が焼き付けられました。キー/値が変更されたときにRedisが自動的に公開しないため、プレーヤーが共有するチャネルを介して移動通知を明示的に公開する必要があることに注意してください。
MongoDBには、発生した変更を監視したりpubsubを実行したりするメカニズムがないため、追加の努力を払えば機能させることができますが、これは適切なオプションではないと思います。
結論として、「大きなLAMPスタック」をCouchDBのみ、Redisのみ、またはノードアプリの背後に配置して、既に提供しているAPIをゲームに適したものにフィルタリング/拡張することができる場合があります。
>頑張ってください！