ウェブアプリケーション

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動

ウェブアプリケーション(Web application)は、ウェブWorld Wide Web)技術を基盤としたアプリケーションソフトウェアである。

概要[編集]

代表的なウェブアプリケーションでは、WebブラウザHTTPを利用してHTMLを取得・表示、それをDOMを介してJavaScriptが操作し、必要に応じてWebサーバと通信をおこなってデータを更新する。このようにウェブ(World Wide Web)を基盤として作られる応用ソフトウェアをウェブアプリケーション(Webアプリ)と総称する。上記の例はあくまでウェブアプリケーションを実現する技術スタックの一例であり、他の様々な技術を用いてWebアプリを作成できる。またウェブアプリケーションの明確な定義は存在しない(動的なウェブページとの差異は不明瞭である)。

ウェブアプリケーションの一例としては、ウィキペディアなどで使われているウィキブログ電子掲示板銀行インターネットバンキング証券会社オンライントレード電子商店街などネット販売ショッピングカートなどを挙げることができる。

ウェブアプリケーションに対して、ローカルのデスクトップ環境上で動作するアプリケーションは、デスクトップアプリケーションやスタンドアロンアプリケーション、スマートフォンで動作するアプリケーションはネイティブアプリと呼ばれる。

Webアプリはクライアント-サーバーモデルを基本としており、WWWを基盤とする分散コンピューティングの一形態ともみれる。2010年代後半には多数のマイクロサービスAPIを介して連携させ構成されるWebアプリも増えており、分散コンピューティングとしての側面がより強くなっている。

特徴[編集]

メリット[編集]

更新が容易である
Webサーバ上のファイルを更新するだけで、クライアントはHTTPアクセスするだけで最新のウェブアプリケーションを利用できる。
クライアント側にアプリケーションのインストールが不要
Webサーバで処理を行って出力結果のファイルをクライアント側(ウェブブラウザ)で表示するだけなのでクライアントはウェブアプリケーションをインストールする必要はない。
ウェブブラウザがあれば環境に依存しない
各クライアント側の環境が違っていてもウェブブラウザがあればクロスプラットフォームに対応できる。

デメリット[編集]

Webアプリの発展に伴って問題点が解決しまた新たな問題が提示される、という流れが続いている。従来指摘されていたデメリットと提案されている解決技術の例は以下である。

  • 標準機能でメディア再生が困難: HTML5 HTMLMediaElementによるメディア再生・制御[1]
  • Webサーバ障害時・通信途絶時に利用不可: PWA(install + Service Worker API[2])によるオフライン動作
  • ネイティブアプリに比較して遅い実行速度: WebAssemblyによるネイティブ水準コード実行[3]

歴史[編集]

1990年にWorld Wide Webが登場しその後ウェブアプリケーションが発明されてから、アプリケーションとしての性能・利便性・UXを高めるために長年にわたり技術開発がおこなわれてきた。

ウェブが誕生した時点ではウェブは静的Webサイトがハイパーリンクでつながれたもの、すなわちWebサーバ上に配置したHTMLファイルをウェブブラウザで閲覧しリンクを飛んでネットサーフィンするものであった。その後CGIの登場により、ユーザからの入力に応じたHTML文書などのリソースの動的生成・返却が可能になった。これにより様々なウェブアプリケーション(あるいは動的Webページ)を構築できるようになった。

CGI以後、Java ServletなどのJava EEApache HTTP Server用のモジュールとしてPHPで記述されたプログラムを実行するmod_php[4]マイクロソフトが開発したActive Server Pagesなどが存在した。その後AjaxAdobe FlashHTML5などが登場した。

2019年現在では特にスマートフォンアプリの分野において「ネイティブアプリと同等な体験の提供」を目的としたプログレッシブウェブアプリと呼ばれる標語に基づいた技術群が精力的に開発されている[5]。またクラウドコンピューティングの発展に伴って、自前のWebサーバではなくフルマネージドクラウドサービスをバックエンドに利用したWebアプリの開発が一部の分野では可能になっている。

技術[編集]

サーバクライアントの間の通信手段は伝統的にHTTPが利用される。HTTPはステートレスなプロトコルであるため、HTTPだけでは状態の管理は行えない。しかし、大半のウェブアプリケーションではセッションの管理が必要であるため、Cookieなどを用いてサーバとクライアント間でセッションIDの受け渡しをし、セッションの管理を行っている。

プログラミング言語[編集]

原則として、Webアプリは特定の言語に束縛されない。バックエンド(サーバーサイド)は開発者が任意にプログラミング言語を選定できる。フロントエンド(クライアントサイド)でもDOMは言語中立な仕様であり、またWebAssemblyを介したC言語Rustを用いた開発も原理上は可能である。ただし実態として、フロントエンドはJavaScriptあるいはTypeScriptをはじめとしたAltJSが主流となっている。

HTML[編集]

従来のWebアプリではHTMLは巨大な1つのHTMLファイルであった。Webアプリの規模拡大に伴ってモジュール化の必要性が高まり、HTMLカスタム要素をはじめとするWeb Components技術によってHTMLの分割が可能になった。

またHTMLの更新はDOMを介した手続き型プログラミングelement.setAttribute()など)によっておこなわれてきたが、宣言型プログラミングとtemplatingによるHTMLの記述(例: lit-html、JSX)がおこなわれるようになってきている。

DOM[編集]

ほとんどのWebアプリはHTMLを基盤技術としており、WebブラウザはDOMを介してドキュメントへのアクセスを可能にしている。Webアプリに求められる性能が高まるにつれて従来のDOM更新速度が不十分になり、DOM更新に関わるいくつかの技術が登場した。仮想DOM(Virtual DOM)、DOM templating(lit-html)はその例である。

通信プロトコル[編集]

サーバクライアントの間の通信手段は伝統的にHTTPが利用される。ただしサイバーセキュリティの重要性が高まりHTTPSがデファクトになりつつある。HTTPを基盤としてより上位の通信プロトコルとしてはgRPC、リアルタイム通信用途ではWebSocketが用いられる。またHTTPとは別系統のリアルタイム通信プロトコルとしてWebRTCも用いられる。より良い通信効率・リアルタイム双方向通信を実現する次世代のプロトコルとしてHTTP/3(HTTP over QUIC)、QUIC等が開発されている。

キャッシュ[編集]

Webアプリはクライアント・サーバーモデルを基本としており、サーバーへのリソースリクエストを高い頻度でおこなう。より高速な動作、ネットワーク途絶下での動作を目的に、リソースのコピーを提供するキャッシュが要件に合わせて用いられる。以下のように、キャッシュはクライアントからサーバーバックエンドまで様々な段階でおこなわれる。クライアントに近ければ近いほどネットワーク遅延は小さくオフライン動作に強く、一方で同期の難しさも発生する。

キャッシュは原理上、同期の問題を常に抱える。なぜならキャッシュとは基本的にコピーされた時間的に古いリソースの提供だからである。ゆえに各Webアプリの要件に合わせた採用が求められる。またPOST時にキャッシュへまず書き込みその後にキャッシュとバックエンドを同期する方式もある。この場合でも同期・競合の問題は原理的に存在する。

アクセス制御[編集]

伝統的にはID・パスワードによる認証AuthN/認可AuthZを用いたアクセス制御がおこなわれてきたが、セキュリティと利便性の観点からトークンベースの手法に移行しつつある。ソーシャル・ログインOAuthOpenID Connect等に対応したクラウドサービスが提供する認証・認可サービス(IDaaS)がしばしば利用される。

データバインディング[編集]

Webアプリではしばしば、データ更新に伴うUI更新・UI操作によるデータ更新をデータバインディングによって暗示的におこなう。React・LitElementなどのフロントエンドフレームワークがデータバインディングを担っている。宣言的に構築したHTML(likeな)UI定義にデータを混ぜることでデータバインディングを実現する場合が多い。

機能による分類[編集]

メディア(動画・音声)[編集]

高レベルの要素から低レベルのAPIまでWeb標準で提供されている。

  • <audio> 要素: src属性の設定のみで再生ウィジェットを表示可能

オフライン[編集]

Webサーバーとの通信(ネットワーク)が途絶している状態をオフラインという。ソフトウェアがオフライン時にも動作するには

  • ローカルに存在するソフトウェアプログラム
  • 失敗するネットワークリクエストの処理
  • オンライン復帰時の同期

などが必要とされる。Webアプリは一般にインストール(プログラムのローカルへの保存と組み立て)を必要としないため、オフライン状態ではそもそもアプリのプログラムにアクセスできない。そのためWebアプリではオフライン対応に特別な仕組みが必要になる。オフライン対応を前提としたWebアプリへの標語として「オフラインファースト/offline first」がある。

ローカルに保存されたプログラム[編集]

Webアプリでは、ブラウザがWebアプリのURLへrequestを送りそのresponseを実行することでアプリが起動・動作する。よってWebアプリのオフライン対応ではまず、ネットワークrequestをインターセプトしローカルに保存されたプログラムを代わりにresponseとして返す、すなわちプロキシキャッシュの仕組みが必要になる。現代のWebアプリではService Worker APIFetchEventCacheによって実現される。Service Worker内で検知されたfetchEventに応じてrequestを止め、事前のアクセス時にキャッシュされていたresponse(プログラム)をCache storageから取り出しrequestへのresponseとする。これによってブラウザへはあたかもオンラインであるかのようにプログラムが返され、オフラインのWebアプリ起動が可能になる。

失敗するネットワークリクエストの処理・オンライン復帰時の同期[編集]

多くのWebアプリは起動後もネットワークを介した情報のやり取りを行う。オフライン時にはネットワーク途絶によりこれらのネットワークリクエストが失敗する。ゆえに

  • 失敗リクエストの処理(適切に失敗し、アプリを落とさない)
  • 失敗リクエストの保存・破棄
  • オンライン復帰時の失敗リクエストリトライ
  • オフラインの間に外部で発生した情報との競合解決・同期

などに対応する必要がある。

例えばGmailなどのメールアプリは、適宜メールサーバーへ新着メールの問い合わせをおこなっている。オフライン時にはネットワーク途絶によりメールの送信ができなくなるが、リクエストを単に破棄すると書いたメールを捨てることになってしまう。失敗リクエスト時にメールを送信待ちリストに加えるのか、あるいは下書きに戻すのかなどが重要な設計項目になる。待ちリストに加える場合はオンライン復帰時の適切な再送信(リトライ)機能が必要である。またオフラインの間にPCブラウザのGmailから下書きを編集し、同時にスマホのGmailからも下書きに別の変更を加えた場合、オンライン復帰時に2つの相反する編集が存在するため、競合を解決・同期しなければいけない。

関連項目[編集]

脚注[編集]

[ヘルプ]
  1. ^ HTMLMediaElement インターフェイスは、 HTMLElement に音声や動画で一般的なメディアに関する基本的な能力の対応に必要なプロパティやメソッドを追加します。 HTMLMediaElement. MDN web docs
  2. ^ Service Workerは、基本的にウェブアプリケーション、ブラウザー、そして(もし繋がっていれば)ネットワークの間に介在するプロキシサーバーのように振る舞います。これは、よりよいオフライン体験を可能にするように意図されており、ネットワークのリクエストに介在してネットワークの使用可否の状況に基づいて適切な対応を取ったり、サーバー上にあるアセットを更新したりします。サービスワーカー API. MDN web docs
  3. ^ WebAssembly は最近のウェブブラウザーで動作し、新たな機能と大幅なパフォーマンス向上を提供する新しい種類のコードです。 WebAssembly の概要 - WebAssembly とは何か. MDN web docs
  4. ^ 他にもPerlのためのmod_perlPythonのためのmod_pythonRubyのためのmod_rubyなどが存在する。
  5. ^ これらのアプリはどこでも動作し、ネイティブアプリと同様の使い勝手を提供する様々な機能を提供します。 プログレッシブウェブアプリ. MDN web docs