ウェブアプリケーション
サービス同士が分離することで単一責任の原則が成立し機能の変更が1つの小さなサービスに閉じ複雑性が低減する。また組み合わせるサービスの種類によって多様なアプリケーションが構成できる。一方でサービスの連携をいかに行うかが重要になる(容易に複雑性が発生する)。機能分割が意識されないアプリケーションはモノリシックと呼ばれる。
連携にWebを用いるという構想から始まり、厳密な連携プロトコルかRESTのような柔軟なプロトコルか、開発工程・デプロイメント・チームビルディングまでを含んだ方法論か、クラウドコンピューティングサービスを前提にするかなど、範囲と標語/キャッチフレーズを変えながら、Webアプリケーションが登場した当初からアーキテクチャの提唱が続いている。プログラムの分割界面という側面では「サービスに着目」という点でドメイン駆動設計に近い思想を持っている。
代表的なウェブアプリケーションでは、WebブラウザがHTTPを利用してHTMLを取得・表示、それをDOMを介してJavaScriptが操作し、必要に応じてWebサーバと通信をおこなってデータを更新する。このようにウェブ(World Wide Web)を基盤として作られる応用ソフトウェアをウェブアプリケーション(Webアプリ)と総称する。上記の例はあくまでウェブアプリケーションを実現する技術スタックの一例であり、他の様々な技術を用いてWebアプリを作成できる。またウェブアプリケーションの明確な定義は存在しない(動的なウェブページとの差異は不明瞭である)。
ウェブアプリケーションの一例としては、ウィキペディアなどで使われているウィキやブログ、電子掲示板、銀行のインターネットバンキング、証券会社のオンライントレード、電子商店街などネット販売のショッピングカートなどを挙げることができる。
ウェブアプリケーションに対して、ローカルのデスクトップ環境上で動作するアプリケーションは、デスクトップアプリケーションやスタンドアロンアプリケーション、スマートフォンで動作するアプリケーションはネイティブアプリと呼ばれる。
Webアプリはクライアント-サーバーモデルを基本としており、WWWを基盤とする分散コンピューティングの一形態ともみれる。2010年代後半には多数のマイクロサービスをAPIを介して連携させ構成されるWebアプリも増えており、分散コンピューティングとしての側面がより強くなっている。
しかしリソースに制限がある場合、キャッシュと最新データの差分(delta)のみを更新することで制限を解決できる。delta sync方式では複数のクエリ、BaseQueryとDeltaQuery(+SubscriptionQuery)が存在する。BaseQueryはキャッシュリフレッシュに相当する全件取得であり、DeltaQueryはデータソースからの差分情報取得である。データソースは更新情報をデータとは別に持っておき、DeltaQueryに応じて更新情報Queueから情報を送り出す。これにより既存データへのアクセスリソースを抑えながら同期が可能になる。DeltaQueryは定期的なfetch実行によって実現でき、リアルタイム更新を求めるならWebSocket等を用いたsubscriptionによる差分情報購読によっても実現できる。
Delta Syncを実装するうえではBaseQueryとDeltaQueryの使い分け、オフライン対応が重要な問題になる。ネットワーク途絶が発生した場合はBaseQueryしなおす設計にするのか、DeltaQueryのリクエスト頻度はどう制御するのか(c.f. exponential backoff+jitter)、Subscriptionの再接続は誰が責任を持つのかなどである。またデータソース側でどう差分情報を生成し保持するのか(生成方法、保存期間・形式)なども重要である。
Webアプリではしばしば、データ更新に伴うUI更新・UI操作によるデータ更新をデータバインディングによって暗示的におこなう。React・LitElementなどのフロントエンドフレームワークがデータバインディングを担っている。宣言的に構築したHTML(likeな)UI定義にデータを混ぜることでデータバインディングを実現する場合が多い。