websocketライブラリ決め

◆Key point

フロントは、Web標準のJavaScript WebSocket APIを利用
サーバーサイドは、Djangoを非同期対応するためにDjangoChannelsを利用
(以下はライブラリの範囲外かも)
サーバーサイドは、ASGIサーバーとしてdaphneを利用
サーバーサイドは、一部の計算高速化のために、インメモリデータベースとしてRedisをコンテナに追加
計算高速化のためにNoSQL DB;Redisを利用すると, MinorModule(PostgresSQL)の要件は満たせないと思う

◆サブジェクトの通信に関連する要求

wssが利用できる
サーバーサイドで、ゲームプレイ、ボールの動き、スコアリング、プレイヤーの相互作用を処理できる
ゲームの初期化、プレイヤーコントロール、およびゲーム状態の更新をサポートするAPIエンドポイントが利用できる
ネットワークの予期せぬ切断や遅延などを適切にハンドリングできる
ゲームの応答性が高い

◆フロント reconnecting-websocket: ReactでWebSocketを扱うで紹介されてた再接続の便利機能っぽいが詳細は未確認

◆バック Django Channels: Djangoを非同期通信に対応させるためのライブラリ。 daphne: ASGIサーバー。APIコンテナでメインプロセスとして動作する。Djangoチームが開発したので、runserver的なワンコマンドで起動できそう。 Redis: メモリでデータを扱う（ボール位置の計算など）場合に、Channelsの（さらに）バックエンドとして機能する。Redisコンテナとして独立したコンテナが必要になりそう。 channels_redis: Django Channels（APIコンテナ）とRedisコンテナを仲介するための、APIコンテナで動作するライブラリ。

◆Ref Socket.IO：Node.js上で機能する、主にバックエンドの非同期通信のライブラリ。フロントと連動して再接続などがChannelsよりも簡単に実装できそう。バックエンドをDjangoで開発する、という要求に違反しそうなので利用しない。 Socket.IO vs Channels: 1, 2 SignalR：.NETフレームワークのリアルタイム通信ライブラリ。APIがDjangoなので利用しない（できない？）。 uvicorn: ASGIサーバー。APIコンテナでメインプロセスとして動作する。高速らしいので、daphneに満足できない場合の選択肢。 WebSocketのRFC：https://tex2e.github.io/rfc-translater/html/rfc6455.html

kaaaaakun / ft_transcendence

websocketライブラリ決め #93