Nodachisoft Nodachi Sword Icon
  
@あまじ✎ 2020年4月17日に更新

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

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

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

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

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

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

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

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

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

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

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

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

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

変更履歴

  • 2020/04/17 記事公開
  • 2020/07/17 概要更新
 
 
送信しました!

コメント、ありがとうございます。

なんかエラーでした

ごめんなさい。エラーでうまく送信できませんでした。ご迷惑をおかけします。しばらくおいてから再度送信を試していただくか、以下から DM などでご連絡頂ければと思います。

Twitter:@NodachiSoft_jp
お名前:
 
連絡先:
 
メッセージ:
 
戻る
内容の確認!

以下の内容でコメントを送信します。よろしければ、「送信」を押してください。修正する場合は「戻る」を押してください

お名前:
 
連絡先:
 
メッセージ:
 
Roboto からの操作ではないという確認のため確認キーを入れてください。
確認キー=95
戻る
 / 
送信確認へ
コメント欄
コメント送信確認へ

関連ありそうな記事(4件)です!

ブラウザでデータの保存

#ブラウザゲーム開発記録✎ 2020-07-17
ブラウザアプリ(Webアプリ)でデータを保存する先について、cookie、webstorage、サーバ側保存を比較し使いどころを整理
広告領域
追従 広告領域
目次
ブラウザゲームでのサーバ通信
ブラウザゲームでのサーバ通信
主にサーバと通信したい内容
主にサーバと通信したい内容
ステートレスとステートフル
ステートレスとステートフル
変更履歴
変更履歴
Nodachisoft © 2020