アプリで基本的なデータフローを制御する

全てのwebアプリの中心は、その内部・外部のデータフローです。webの進化につれて、データフローはずっと複雑になりました。これをマスターすると、もっと良くて効率的なwebアプリを作るのに役立ちます。

基本的な HTTP のデータフロー

始まりから、Web はHTTP プロトコルによって支えられたクライアント/サーバ アーキテクチャを基礎としていました。

上記の図は基本的なwebサイトのフローを示しています。各リソースはサーバ上でホストされて、クライアント (web ブラウザ) はそれらが必要となる度に、 HTTP 経由でリクエストします。この構成では、webブラウザはwebコンテンツを表示する責務だけを担います。全てのデータとその処理は、サーバで取り扱われます。

アーキテクチャの明白な簡潔さにだまされないで下さい。これはまだ有効であり、今日多くのwebで使われています。これについて使える大きな理論的成果があり、 REST アーキテクチャとして知られています。このアーキテクチャは、どうやってリソースがアクセスされるかや、HTTPプロトコル経由でどうアクセスされ、取り扱われるかを記述しています。もし REST と HTTP が独立であっても、アプリにとってこれを知ることは、頑丈なサービスとHTTP経由のリソースアクセスを作るのにとても役立ちます。

その簡単なアプローチの欠点は、ユーザがwebページを見たいと思った時に、同じページ同士であっても、毎回全ての資産を再度リクエストするのが必須である事です。これにより、画面の遅延や、 FOUC などのような、望ましくない視覚上効果の元となります。痛みをなるべく避けるため、少なくとも不要なネットワークリクエストを避けるため、webブラウザはリソースのキャッシュを制御します。しかしそれでも完全にページをレンダリングすることもあり、悲しいかなこの操作は時間がかかり、ユーザにとって気づかれてしまうでしょう。

進んだ webサイトのデータフロー

90年台の終わりに、Microsoft はリソースに何度も何度もリクエストが必要となることを回避する技術的手法を打ち立てました。この解決法はAJAX と言って、それはXMLHttpRequest という新しい JavaScript オブジェクトを基礎としています。

この技術で導入された主な変更点は、いつ、どこで HTTP リクエストが処理されるかという事です。この技術を使って、HTTP リクエストはハイパーリンクのような組み込みwebブラウザの機構ではなく、直接webページで処理できるようになりました。その変更のおかげで、webページはリソースが必要な時にだけ、いつでもリクエストする機会を得ました。初めは、それはwebページの一部を更新する HTML や XML の断片にリクエストするものと考えられていました。今日では、ページコンテンツの更新に必要となるデータのリクエストに使われます (通常は、しかし必ずではなく、 JSON フォーマットで) 。これが技術的な観点で少しの違いならば、アーキテクチャの観点で何も変わりません。

今日の最も大きなwebサイトは、この技術をとても徹底的に使っていますが、いつ使えば良いのかと、いつには不要なのかを知るのは重要です。

Web アプリのデータフロー

最近、webブラウザで新しいテクノロジーが定着し始めています。それは IndexedDB とAppCache と offline events　です。最初のぶんはブラウザに直接組み込まれたデータベース以上ではありません。これはサーバにジョブをリクエストすることなく、ローカルにデータを貯めて操作します。2つ目のぶんは新しいアプリのキャッシュメカニズムで、キャッシュ (データでなく) リソースへのアクセスを永続化できます。いったんこのメカニズムでリソースがキャッシュされると、ブラウザはそのリソースに対して再度リクエストすることは決してなくなります。最後のぶんは、いつブラウザがネットワークに繋がったかを知るための API です。

Those three technolgy change many things. Thanks to them, the connection to the server is no longer a preriquistery to use a web site. For that reason, such web sites are called web application. At that point, the whole life cycle of the application can be handled inside the browser. However the server is still useful, but only for two point:

• A first connexion is required to "install" or "update" the application (caching ressources, setup data schema, etc.)
• The server can be used to backup the applications data to prevent any issue on the local machine or for users who use several browsers or computers to access the application.

HTTPを超えて

How other technologies fit into our data flow architecture, including Web sockets, WebRTC (but this is advanced stuff: defer detailed discussions to the advanced network communication section).

さらに深く進む

We need to write separate follow on articles covering the following:

1. HTTP basics, and how this can help you be a better master of your data. For this part it may be a good idea to take a look at what HTTP information is currently available on MDN and refresh/reshape/update/reorganize that content
2. Ajax basics (architecture, technique)
3. Data storage systems and Ajax
4. Intro to handling offline AJAX and timeouts
5. Handling data within the browser (persistant or temporary; technique with cookies vs. storage vs. IndexedDB vs. data attributes). For offline stuff, defer to the Offline section
6. Advanced Ajax topics, such as UI interaction and perceived performance.
7. Links to other useful demos and resources