AJAXクライアントストレージスタディ-Dojo手術からネイティブFullajaxストレージ実装まで

Webアプリケーションの集中的な開発により、クライアント側で大量のデータを保存することがますます一般的になっています。 これは、アプリケーションを単純化するだけではありません。多くの場合、クライアントストレージシステムを使用することで、作成したアプリケーションの機能を大幅に拡張し、それ以外では不可能なことを実行できます。



同時に、これはいくつかの特別でエキゾチックなWebサービスの開発者の「気まぐれ」と見なされるべきではありません。 blogspot.com/2008/05/myspace-message-center-is-now-searching.html ）。 ネットワークには、ローカルリポジトリの使用に関する多数の出版物があります。たとえば、資料の準備中に調査した以下の出版物に注目できます。



browserpersistence.ru

abrdev.com/?tag=storage

pablotron.org/software/persist-js



ローカルストレージとは何なのかわからない場合、または慣れていない場合は、上記のリンクでストレージとそのアプリケーション領域に関する包括的な情報を見つけることができます。

ローカルデータストレージを実装するためのすべての可能なオプションを検討した結果、現時点で最も魅力的なのはFlashベースのストレージです。 永続的なデータストレージ、つまり、そこにデータを保存することについて話していることに注意してください。ブラウザでページを閉じ、更新し、さらにはコンピューターを再起動した後でも、クライアントコンピューターでデータにアクセスできることを期待しています。 この記事では、Flashベースのストレージの実装を分析します。

フラッシュストレージの明確な利点を見てみましょう。

• ブラウザー間の最大アクセシビリティ（明らかな理由により、Webに共通のテクノロジーをサポートしないエキゾチックなブラウザーオプションは考慮していません）。
• 最大の普及率：Flashは95％以上のブラウザにインストールされています。
• ほぼ無制限の量のデータを保存する機能（一部の予約では、たとえば、ユーザーが指定されたボリュームの保存を明示的に許可するか、無制限の量の情報を保存する許可を設定する必要があります）。

一部の開発者は、バナーのためにユーザーがFlashをブロックするというデメリットをこの方法に起因する傾向がありますが、私はこの問題をより遠いものと考えています。 もしそうなら、彼らはグラフィックスとスクリプトをオフにします-つまり、彼らが「自分自身のピノキオ」と言っているように-現在、Flashは多くのサイトの不可欠な部分であり、Web環境でマルチメディアを実装するための唯一の許容可能な技術です。

分析したすべてのFlashストーリーの中で、機能面で最も魅力的なのはストーリーであり、これはDojoライブラリ（dojotoolkit.org）の一部であることに注意してください。 さらに、概して、これはこの技術の最初の産業実装です。

顕著な利点：

• JSオブジェクトを保存する機能、自動シリアル化および逆シリアル化（もちろん、JSON形式）。
• Flash ExternalInterface操作のいくつかのバグが考慮されました。
• データウェアハウスを操作するための強力で汎用的なAPI。
• 保存されたデータの組み込み名前空間のサポートは、同時に複数のリポジトリで動作します。
• 保留中のステータス。
• 現在のストレージサイズの制限を超えた場合-サイズを増やす許可を求めるダイアログが自動的に表示されます。

もちろん、このソリューションにはすべての利点がありますが、欠点がないわけではありません。

• 大規模な配布ボリューム（ストレージシステムにのみDojoを使用する場合）。
• リポジトリを初期化するときに、不要なコードをロードします。これは、アプリケーションの実行時には必要ない場合があります。
• ローカルファイルシステムファイルからスクリプトを実行する場合の動作不能：//

テスト例download.dojotoolkit.org/release-1.1.0/dojo-release-1.1.0/dojox/storage/tests/test_storage.html?forceStorageProvider=dojox.storage.FlashStorageProviderは13（！）スクリプトをロードします。 それらはすべてAJAXを使用してロードされます。FlashStorageを使用するよう明示的に指定した場合でも、このストレージが機能するために必要ではない多くの追加ファイルがロードされます。



最も単純なhelloworldの例は、 download.dojotoolkit.org / release-1.1.0 / dojo-release-1.1.0 / dojox / storage / demos / helloworld.htmlが少なくともいくつかのJSスクリプトをロードすることです。 したがって、アプリケーションがDojo Toolkitの機能を使用しない場合、それを使用してストレージのみを実装することは非常にリソースを消費し、効率的ではないと結論付けることができます。



「欠点の根本」は同じであるため、これらの欠点を取り除くか、少なくとも影響を最小限に抑えることにしました。 Dojo 1.1ディストリビューションをダウンロードした後、フラッシュストレージのみを個別に分離するために、そのアーキテクチャを分析するために座っていました。 これが最初の困難が判明した場所です。 主観的に、Dojoの内部アーキテクチャは非常に重要で複雑です（もちろん、これはおそらく最も最近のいくつかのプログラミングパラダイムを使用してJSで実装されたすべての最も強力なフレームワークであるため、最近、アスペクト指向プログラミングを実装するためのモジュールで補充されました）。 したがって、フラッシュストレージを個別に単純かつ個別に分離することはできませんでした。 しかし、これらの欠点を解消したいという願望は、遭遇した困難以上のものであることが判明しました。



作業の最初の段階では数時間の作業が必要でしたが、このバージョン（コードの内部アーキテクチャを変更せずに）の重量は100 Kb（Dojoコア+ストレージモジュール）を超えていました。 綿密な分析を行ったところ、まだ多くの過剰が残っていることがわかりました。 この超最小化バージョンをさらに圧縮するための第2段階は既に数日かかり、この実装にはわずか15 KBしかかかりません。これには、Dojo Toolkitのソースコードに対する膨大な変更が必要になります。



Flash Storageのより詳細なテストでは、もう1つの利点が示されました。ストレージは、コンピューター上のすべてのブラウザーで同じです。 Firefoxを使用して保存されたデータはInternet Explorerから簡単に取得され、その逆も同様です。



追加の欠点も確認されました。フラッシュストレージが初期化されるまで待つ必要があります。 つまり、ストレージのフラッシュクリップがロードされた後、ストレージの使用は非同期モードでのみ可能です。 したがって、Flash Storageを使用するWebアプリケーションは、これを考慮して設計する必要があります。



ただし、単にクライアントにデータを保存し、アプリケーションが機能するためにそれを受信する機能だけが機能ではありません。 このようなキャッシュ内のデータを制御し、サーバー側から自動的に更新できるようにしたいです。



ローカルストレージを使用する場合、非常に重要な点は、クライアント側でのデータ更新アルゴリズムの実装です。 3つの異なる実装オプションに注目してください。



グローバルサイトのバージョン管理の方法



このメソッドのアルゴリズムは、SVNの実装の原理に似ています。 サイトにはグローバルバージョン番号があります。 個々のコンテンツの変更またはコンテンツのグループの変更により、バージョン番号が増加します。 サイトの最初のロード中に、クライアント側のバージョン番号がサーバーに送信されます。 サーバーは、クライアント上の送信されたバージョンとサーバー上の現在のバージョンを確認し、違いがある場合は、サイトのクライアントバージョンとサーバーバージョンの違いに応じて、コンテンツの変更された識別子キーのリストが生成されます。 つまり、サーバー上のコンテンツを変更すると、コンテンツキーのリストがクライアントに送信されます。これはリポジトリで削除する必要があります。 このリストは、クライアントのサイトのバージョンとサーバー上の現在のバージョンの違いに対応しています。 同時に、コンテンツ自体はクライアントに送信されません。 コンテンツが送信されるのは、クライアント側が特定のデータを要求し、正常にロードされるとリポジトリに到達した場合のみです。



アルゴリズムの元の画像fullajax.ru/doc/storage/Storage-Algorithm-1.jpg



考慮されたアルゴリズムにより、サーバーへの接続数と送信される情報の合計量が削減されます。 この方法は、多数のコンテンツユニットで使用すると便利です。



個々のコンテンツユニットをバージョン管理する方法



このアルゴリズムは、コンテンツの特定の各部分の一意性を識別することに基づいています。 一番下の行は、サイトが起動すると、値ペアのリスト{key：novelty identifier}がサーバーから取得されるということです。 クライアントスクリプトは、リポジトリ内の一致する新規識別子をチェックします。 違いがある場合、ノベルティ識別子の古い値と更新されたコンテンツキーに対応するデータがリポジトリから削除されます。 すぐにリポジトリに新しい識別子の新しい値が記録されます。 前述の方法と同様に、コンテンツがクライアントに送信されるのは、クライアントが特定のデータを要求した場合のみであり、正常にロードされた場合、リポジトリに入力されます。



アルゴリズムの元の画像fullajax.ru/doc/storage/Storage-Algorithm-2.png



考慮されたアルゴリズムにより、サーバーへの接続数と送信される情報の合計量が削減されます。 このアルゴリズムは実装が簡単であり、その使用は少数のコンテンツユニットで効果的です。 コンテンツユニットの数が多いと、値のペア{key：novelty identifier}のリストが大きすぎて、このアルゴリズムの有効性が低下する可能性があります。



Etagを使用するための標準的な方法



この方法は、コンテンツIDをEtagサーバーに送信することに基づいています。 クライアントで送信された識別子が現在のサーバー識別子と一致する場合、サーバーは304 Not modifiedと応答し、クライアントはストレージからデータを取得します。 識別子が異なる場合、サーバーは新しいコンテンツで応答します。 新しいコンテンツを正常にアップロードしたクライアントは、リポジトリ内の古いデータを新しいデータに置き換え、Etagノベルティ識別子を書き込みます。



考慮されるアルゴリズムは、送信される情報の合計量のみを削減します。 この方法は簡単に実装できますが、サーバーへの接続数の点では、以前に検討されたアルゴリズムと比較すると効果が低くなります。



このアプローチまたはそのアプローチの使用の選択は、特定の状況に依存します。



応用例



Flash Storageの使用は、Webアプリケーションの構成データとオブジェクトを保存するだけでなく、スクリプト、スタイル、写真、さらにはコンテンツ自体を保存するのにも便利です。 ストレージの適用例は、すでに知られているサイトfullajax.ruに実装されています。 このサイトでは、クライアント側のデータを更新するために、上記の「個々のコンテンツをバージョン管理する方法」が適用されます。 スクリプトとコンテンツはリポジトリに保存されます。 次回このサイトのページを読み込むと、新しいバージョンのページがサーバーに表示されるまでリポジトリから取得されます。



AJAX + Storageバンドルを使用すると特に効果的です。 Fullajaxライブラリには、フラッシュストレージを実装するためのモジュールが含まれています。 既にFullajaxライブラリを使用しているユーザーの場合、追加のスクリプトを接続するだけで十分です。AJAX（daxまたはhaxメソッド）を使用してデータを要求すると、データは自動的にストレージに送られます。 クライアント側でデータを更新するメカニズムを処理するだけです。



もちろん、この実装だけではありません。 そして多くの場合、個々の機能が非常に不足しています。 私はそれを隠しません-Google Gearsの組み込みDBMSは本当に最良のオプションですが、このソリューションは非常に排他的であり、Webアプリケーションの特別な場合にのみ効果的に使用できます。 通常のWebサイトを含む大規模な使用では、上記のソリューションを使用するか、BrowserpersistenseやPersistJSなどの汎用ソリューションを使用するのが最適です。



資料の著者：Ruslan Sinitsky（sirus、 fullajax.ru ）、共著者-Alexander Lozovyuk（aleks_raiden、 abrdev.com ）。