ウェブアプリケーション
サーバとクライアントの間の通信手段は伝統的にHTTPが利用される。HTTPはステートレスなプロトコルであるため、HTTPだけでは状態の管理は行えない。しかし、大半のウェブアプリケーションではセッションの管理が必要であるため、Cookieなどを用いてサーバとクライアント間でセッションIDの受け渡しをし、セッションの管理を行っている。
より良いアプリケーションを目指しWebアプリは日々機能が強化され、同時に複雑性も増加している。複雑性に対応するため、様々なソフトウェアアーキテクチャが利用・考案されている。WebアプリはWebすなわちネットワークを介した分散コンピューティングとしての側面を持つため、それに応じた特性をもつアーキテクチャが選ばれる場合が多い。
Webアプリはクライアント・サーバーモデルを基本としており、サーバーへのリソースリクエストを高い頻度でおこなう。より高速な動作、ネットワーク途絶下での動作を目的に、リソースのコピーを提供するキャッシュが要件に合わせて用いられる。以下のように、キャッシュはクライアントからサーバーバックエンドまで様々な段階でおこなわれる。クライアントに近ければ近いほどネットワーク遅延は小さくオフライン動作に強く、一方で同期の難しさも発生する。
アプリ内キャッシュ
client-side proxy: Service Worker API Cache
ブラウザキャッシュ:HTTPキャッシュ(HTTP ETag)
Web Proxyキャッシュ
コンテンツデリバリネットワーク(CDN)
BFFキャッシュ
DB in-memoryキャッシュ
キャッシュは原理上、同期の問題を常に抱える。なぜならキャッシュとは基本的にコピーされた時間的に古いリソースの提供だからである。ゆえに各Webアプリの要件に合わせた採用が求められる。またPOST時にキャッシュへまず書き込みその後にキャッシュとバックエンドを同期する方式もある。この場合でも同期・競合の問題は原理的に存在する。
同期の手法として差分同期(delta sync)がある。同期のもっともシンプルな方法はキャッシュのリフレッシュ、すなわちすべてのデータを再取得する方法である。充分な計算・通信リソースがあるならば全てのデータが最新であることを容易に保証できる。
Webアプリでは外部データベース等へのデータアクセスがしばしばおこなわれる。リモートデータの場合、クライアントはfetchAPIが基礎技術としてあり、データ側のスタイル・仕様としてはREST、GraphQLが存在する。データスキーマ仕様にはRESTに対応するOpenAPI Specificationがあり、GraphQLは仕様にスキーマの定義がある。