はじめに

Qiitaに何か記事を書いておくといい事があると聞いて、書いてみる事にする。
今後技術系の記事は全部こっちに書く。
というわけで前々から思っていた現在のWebの気にくわない所を書こうと思う。
言い古された事だと思うので、流れてきて間違って開いてしまった人は申し訳ない。

条件

現代のWebの条件・制約は、

一度のアクセスで見込まれる収入は僅か。
1. ユーザーはWebサービスは無料だと考えている。直接料金を負担する事は稀。
2. 広告による収入が主になる。その額はバナークリック一度で10円程度。
ユーザーの持つハードウェアは機能的制限はほぼない。性能はばらつきがあるが、企業が利用できるそれとけた違いではない。
1. サーバーでできる事はたいていクライアントでもできる。
2. ユーザーはWebにアクセスするのに、一カ月に数千円をISPに、一日数円を電気代に、寿命2～10年で3～20万円の機械を購入する。また時給換算数千円な時間を一日数時間費やす。
3. ユーザーは処理にかかるコスト自体は無視する。
4. ユーザー体験と時間は重視する。
アクセスのほとんどは外部の検索エンジンから。。
悪意のある攻撃者が多数いる。ユーザーを信用できない。
各種の秘密や著作権を保護しなければならない。
作業者は多数いる。分業化されている他、能力にばらつきがある。
1. エンジニアは大量にいるが、技術にばらつきがある。
2. デザイナーは大量にいるが、技術は理解できない。

であり、結果として以下を意識しなければならない。

条件1.から少数のサーバーで多数のクライアントを支える事になる。
1. 性能の合計では、クライアントが遥かに大きい。
2. 従って処理はできるだけクライアントにやらせた方がいい。
条件6.から検索エンジンに意味を理解させなければならない。検索エンジンはあまり賢くない。
認証やセキュリティには気を付けなければならない。
1. セキュリティの領域は動きが早く、手元の技術者が追従できるとは期待できない。
2. 従って認証やセキュリティが問題になる部分は共通化するべき。サービス運営者はできるだけ手を触れるべきではない。
3. サーバーソフトウェアは随時更新が必要で、アプリケーションはその阻害をしてはならない。
デザインとロジックは分離するべき。
1. デザイナーにはデザイナーの仕事を、プログラマーにはプログラミングをやらせるべき。互いに侵犯は避ける。
2. 出来ればやり取りは最小限にしたい。

現状

静的サイト

静的サイトは話が簡単。

サーバー上に、HTMLとその他の素材が置いてあるだけ。
クライアントがデータを受け取り、描画を行う。
通信は画面遷移する度(ページ毎)に発生し、その度少し待たされる。

評価

ユーザーに渡されるデータは構成要素が個別のファイルに分かれている。その結果以下のようになる。

解析しやすい。コピー・改竄しやすい。
全体を表示するのに最低でも2往復が必要。
多数のセッションが発生する。
サーバー側では多数のランダムアクセスが発生する。
テキストデータは通常、圧縮されていない。
共通してアクセスされるデータは容量の重複がなく、キャッシュも効く。

これらはHTTP/2でかなり改善されている。gzip圧縮も可能。

また、テキストエディタで操作できるようなファイルが直接置かれている。いわばコンパイルされていない。結果、

一貫性は保証されていない。例えばリンク切れがありうる。
エラーがない事は保証されていない。エラーが出たら拒否という戦略が出来ず、ブラウザが複雑になる。
専用ソフトがなくても公開できる。手軽。

動的サイト

ユーザー毎に異なる情報はRDBMSに保存される。
1. RDBMSはHTTPサーバーと通信する。認証は一度で、それにより全権限を有する。
2. RDBMSはユーザーと通信を行わない。
3. データはいくつかの変数と他のレコードへのリンクを含むレコード。
4. 入れ子状の情報も記録できるが、構造は固定。
RDBMSから受け取った情報をアプリケーションサーバーが処理する。
1. 大抵は文字列処理で行う。XMLとしての妥当性は検証しないのでたまにエラーが起きる。
2. HTTPサーバーは動的処理を担わなければならない。
認証はHTTPサーバーが担当する。
1. 大抵は自前で行う。ライブラリを使う場合もある。処理としては単純。
2. RDBMSの認証とは別。

問題点

HTTPサーバーで行える処理には限界がある。
1. コストを考えれば文字列処理だが、表現性に限界があり手間がかかる。文字列処理でも処理コストは無視できない。
2. 画像処理などは手軽ではない。
3. ユーザーが自分のデータにGUIなしでアクセスする正当な手法が提供されていない。
4. 逆にスクレイピングが出来てしまう。が、不確実だ。
セキュリティ上の問題が発生しうる。
1. 認証周りでバグやミスが起きうる。
2. HTTPサーバーはRDBMSに対する全権限を持っているので、最悪の場合全データが流出する。
デザイナーとプログラマーの分業が難しい事がある。
1. 採用する言語にもよる。
2. 分業できなければ、時代遅れなデザインのサイトとなりかねない。色々とコストも増える。

ちなみにコストをかければサーバーサイドで画像処理も可能。
古い例ではgifのアクセスカウンターがそう。
PDFを一ページ毎画像として表示するというのも有料サービスなどでは有効だ。元データを渡さないで済むメリットがある。

AJAXサイト

HTTPサーバーはUI等は静的ファイルとして、動的要素はAPIとして提供する。
APIはRDBMSとやり取りし、クライアントに情報を提供する。
クライアントはHTMLファイル等とJavaScriptファイルを受け取る。JavaScriptがHTMLを書き換える。

問題点

JavaScriptの仕事が多い。
1. UI周りと情報の受け取りをすべてやらなければならない。
2. 処理は煩雑になりがち。しかも待ち時間を考慮しなければならない。
3. JavaScriptは素晴らしい言語とは言えない。生産性も低い。
キャッシュ管理に問題がある。
1. 通常APIへのアクセスはキャッシュされない。
2. ページ遷移をすれば再読み込みとなる。操作は初めから。
3. ページ遷移なしの画面更新が頻発するので、データの喪失が起きかねない。
4. 操作毎にページ遷移扱いになる場合は、ブラウザバックなどが利用しづらい。
API作成には多少の手間がかかる。一貫性の保証ができない。
1. RDBMSの構成更新に追従できている保証はない。
2. 認証も担当するのでやはりバグは起きうる。
検索エンジンから無視されかねない。
1. 動的サイトはクローラーからは静的に見える。しかし、AJAXサイトはそうではない。
2. また、特定の画面状況へのリンク自体作成不可能でもありうる。

改善案

XMLサーバー

HTMLとかJavaScriptとかそういうのは変えないサーバーサイドだけの改善案。

HTTPサーバーは静的にファイルの提供のみ行う。
動的要素はXMLデータベースに格納する。
XMLDBは認証周りも行い、一機能として標準化され、バージョン更新でセキュリティ対応できる。
XMLDBはデータ格納時XML Schemaあるいは任意のサーバー言語でチェックする。
XML Schemaの更新時は、バージョン更新用のXSLTまたはJavaScriptを登録する。バッチ処理で適用して行く事も、アクセス発生時に適用する事も、ユーザー側で処理させる事もできる。
1. ユーザー側処理の可能性を棄てて任意の言語にする事もできる。また必要ならXML Schemaのチェックの省略も可能。
ユーザー側での書き換え処理はJavaScriptが担当。

さらに場合によっては以下にするが、こうすると現状とさして変わらない。非推奨。

複数のファイルの合成も可能とする。
バックエンドにRDBMSも可能とする。

もちろんJSONにしても似たようなことはできる。

メリット

認証が共通化され、RDBMSのそれがなくなる。バグが起きにくい。
XMLDBバージョンを更新すればセキュリティの問題が発生しない。
XML Schemaを公開すればアプリも作りやすい。
HTTPサーバーは静的ファイルの提供だけで済む。楽。
XMLDBサーバーはそれほど複雑ではない。

デメリット

やはりJavaScriptの面倒な作業は解消されない。XML SchemaがあってもJavaScriptでは手間がかかる事は変わりない。
普通のWeb APIと比べて大きなファイルを提供する事になり通信料が増える。
XML Schemaによる検証コストはそれなりに大きい。
XSLTは重い。
1. 任意の言語でも別に問題はない。
XMLのサイズは予想しづらい点があり、負荷の予想が困難になりうる。
1. RDBMSと同じようなデータならさほどばらつかない。
数字やバイナリを文字列として格納すれば容量が増える。
1. サーバーの工夫で何とかなるだろう。

続く

とはいっても全く不十分だ。
根本的解決にはHTMLやJavaScriptを何とかせねばならない。
HTML 5やECMAScript 2015などでは不十分だろう。
それは次回に続く。

Webの気にくわない所 その1