ブラウザゲームでのサーバ通信

#ブラウザゲーム開発記録

ブラウザアプリを作るとき、クライアントである Webページ側からバックエンドのサーバと通信することがよくあります。

そんな時、ステートレスとステートフルのどっちを適用するか、メリット・デメリットなどをまとめた備忘です。

主にサーバと通信したい内容

大きくユーザ情報、ユーザからの操作によるマスターデータ変更の情報

サーバ側にプレイヤを特定する情報（IDやパスワード、OAuth 等の外部サービスの認証認可を利用した利用者側のユニークなキー情報）に紐づくように保存するデータを送信することでクライアントが変わったときでもデータの引継ぎができます。

ステートレスとステートフル

ステートレス（stateless)とステートフル（stateful）のどちらでWebアプリゲームを実装するかは、作成するゲームによっても異なると思います。

はっきりとステートレスとステートフルで分けるのではなく、一部のステートフルな技術を使用してアプリを構築することもアリと考えます。

ステートレスな Web API でのデータ連携。SOAP 形式や JSON 形式を利用。
ステートレスな Web API でのデータ連携。セッション利用等、一部のみステートフル。通信は SOAP 形式や JSON 形式。Cookie も連携してセッション管理を行う。
ステートフルで Form を GET / POST することでのデータ連携。昔ながらの MPA を想定。セッション管理を行う。

ステートレスに近づく程、クラウド上で Kubernates を使ったコンテナ自動追加で負荷分散しやすくなったりします。ただし、認証関連情報の共有や全体の合算した必要なＣＰＵ処理は大きくなりがち。あとステートレスの良さを活かそうとすると、クラウド上に負荷分散サーバや Kubernates などのサービスを利用する流れになり、お金がかかります。

当サイト（Nodachisoft）のように小さい組織で、貧乏なサイトがアプリ構築することを考えたとき、とりあえずアクセス規模を考えて完全ステートレスではなく、中間（上の２番）くらいのサーバ連携方式に留めています。アクセス量が増えた時に、コンテナ化＋Kubernates 利用に切り替えるかもです。

※作成した無料Webゲーム（旅マギ）の認証関連は、2020年4月時点では、ＩＤとパスワード方式、Twitter の OAuth1.0 での外部認証方式、Google の OAuth2.0 での外部認証方式に対応させています。