今回はサーバ側へのデータ保存機能追加について。

機能概要

IDとパスワードを登録、機体構成や所持素材、パーツなどを登録できる機能。
登録情報のアクセス権限などはいったん全て実装項目から外し、「記事編集にパスワードが必要な掲示板」レベルとした。本当に編集の鍵をかけて自分用データを作れる、程度。

認証系

基本的なスタンスとして、「ログイン状態制御は自力で実装するべきではない」と考えているため、「ログイン状態」という物自体が存在しない。表示しているIDの情報を変更するときに都度パスワードを要求する形になっている。

（※）
作業時にID・パスワード認証を要求するのとログイン状態を持って作業権限を与える物は似ているように感じるかもしれないが、後者を自力で実装しようとすると考慮するべき項目が大きくなり、必要な開発資源、バグの存在ともにほぼ確実に増加する。
フレームワークを使うという選択肢があればそれを、何らかの理由で独自実装しなければいけないならば極力機能を絞ってテストを念入りに行わないといけない。閉じたネットワーク内で悪意のアクセスを考慮しないという割り切りが許されたとしても（！）データ破壊などにつながる可能性がある。
「ログイン状態」を持つシステムが欲しいならば実績あるフレームワークを使うべき。そのための調整にかかるコストはおそらく、独自実装に必要な試験コストや発生したバグへの対応コストと比べれば相当安い。

データストレージ

MySQLを選択。BigTableとGoogle App Engineはまた今度。

本来的にはBigTable向けのデータ形式なのだが、まあこの程度の件数（IDは現在50ほど、仮に500件まで増えても何も変わらないだろう）ではパフォーマンス上何も起きないだろう。
割と大きな粒度でDB格納している。
所持素材やパーツを全て正規化した形でDB設計を行うという選択肢はあったのだが、1問い合わせで100件単位のJOINが発生する上に、そもそも得たいデータの粒度と乖離しすぎるので却下した。

通信

セーブ・ロードともにAjax通信で実現。
なお、セーブタイミングは明示的にセーブボタンを押したときのみ。技術的に言うならばもっと細かくアセンブルパーツ変更ごとに通信させる事はできるのだが、レスポンスばかり悪化させて、欲しくもない試行錯誤中の細かすぎる保存は好まれないだろう。
ある程度動かして値を見て決定、あるいは素材とパーツの情報を入力し終わって保存、という流れを想定している。

アクセス・サーバ負荷

サーバ付属のアクセス解析を見ると1日あたり2000から2500ページビュー。
他のコンテンツが実質無視できる程度しかヒットしないので、そのままシミュレータの負荷と考えてよい。さすがにサーバプランで最安のものだと突発的に限界を超えかねないので少し良いプランにしていたりする。
アップデート直後にはアクセスと転送量が増え、キャッシュが効くと転送量はいくばくか軽減される傾向。普通に使う分には今のところ大丈夫そうだ。

クライアント負荷

豪快にメモリとCPUを使う関係上、注意書きに追記。
このシステムは「（動作が）速い」方向で作ってはいるが、「（負荷が）軽い」ものではない。操作のレスポンスという点で言えば確かに「軽く感じる」ようにはしているが…。
徐々に遅延評価などで見直してはいるものの、最大の理由である固定データの保持方法が設計思想として変更されないので劇的に軽くなることは残念ながらないと思う。

総合して

「サーバにデータを保存する」ということを実現した段階。これだけ単純化してもバグの発生率は増えるし開発と試験も面倒になる。
例えばAjaxは同一ドメインのデータしか基本的に取れない（CGI経由でインチキをするなどはある）ので、試験の際にはローカルで環境を作るか、もう一つサーバ側に試験環境を作るかが必要になる。

開発経験もあって、DB周りにはそれほど手間は取られなかった。一応はCGI＞DBの接続で情報は集めたが、今はライブラリも枯れたものがあるので簡単である。

本当に必要なのは、どの機能を追加してどこで公開して、どう修正して行くか。DB設計ともども、「決心」するべきものであって完全な答などないのだ。