031.2 レッスン 1

モバイルやデスクトップのアプリケーションには、インターフェイスがHTMLからレンダリングされ、ブラウザと同様にプログラミング言語としてJavaScriptを使用できるものがあります。しかし、ブラウザに読み込まれたクライアントとは異なり、ネイティブクライアントが機能するために必要なHTMLと必要なコンポーネントは、アプリケーションのインストール時からローカルに存在しています。実際、このように動作するアプリケーションは、HTMLページとほとんど同じです（両者は同じエンジンでレンダリングされる可能性さえあります）。また、 プログレッシブWebアプリ（PWA：Progressive Web Apps） と呼ばれる、サーバとの即時通信を必要としない機能に限定して、オフライン用にWebアプリケーションのクライアントをパッケージ化する仕組みもあります。アプリケーションの機能については、ブラウザで実行してもPWAでパッケージ化しても違いはありませんが、後者の方がローカルに保存される内容を開発者がよりコントロールできるという点が異なります。

HTMLからインターフェースをレンダリングすることは、非常に繰り返し行われるアクティビティであるため、エンジンは通常、オペレーティングシステムに含まれる独立したソフトウェアコンポーネントとなっています。別のコンポーネントとして存在することで、アプリケーションパッケージに組み込むことなく、さまざまなアプリケーションに組み込むことができます。また、このモデルでは、レンダリングエンジンのメンテナンスをOSに委ねることで、アップデートを容易にしています。このような重要なコンポーネントを最新の状態に保つことは、起こりうる障害を回避するために非常に重要です。

配信方法に関わらず、HTMLで記述されたアプリケーションは、エンジンが作成した抽象化レイヤー上で実行され、分離された実行環境として機能します。特に、ブラウザ上で動作するクライアントの場合、アプリケーションが自由に使えるのは、ブラウザが提供するリソースだけです。ページの要素を操作したり、HTTPでファイルを要求したりといった基本的な機能は常に利用できます。ローカルファイル、地理的な位置、カメラ、マイクへのアクセスなど、機密情報を含む可能性のあるリソースは、アプリケーションが使用する前に、ユーザーの明示的な承認が必要です。

サーバ上で動作するクライアント側のWebアプリケーションの中心となるのがHTMLドキュメントです。HTMLドキュメントは、ブラウザが表示するインターフェース要素を構造化して表示するだけでなく、クライアントの正しい表示と操作に必要なすべてのファイルのアドレスを含んでいます。

HTMLだけでは、より精巧なインターフェースを構築するための汎用性が低く、また、汎用的なプログラミング機能も持っていません。このため、クライアントアプリケーションとして機能すべきHTMLドキュメントには、必ず1セット以上のCSSとJavaScriptが付属されています。

CSSは、別のファイルとして提供される場合と、HTMLファイル自体に直接含まれる場合があります。CSSの主な目的は、HTMLインターフェースの要素の外観やレイアウトを調整することです。厳密には必要ではありませんが、より洗練されたインターフェイスでは、通常、ニーズに応じて要素のCSSプロパティを変更する必要があります。

JavaScriptは実質的に不可欠なコンポーネントです。JavaScriptで書かれたプロシージャは、ブラウザ上のイベントに応答します。これらのイベントは、ユーザーによって引き起こされるものもあれば、非インタラクティブなものもあります。JavaScriptがなければ、HTMLドキュメントは実質的にテキストと画像に限られてしまいます。HTMLドキュメントでJavaScriptを使用すると、ハイパーリンクやフォーム以外にもインタラクティブ性を拡張することができ、ブラウザが表示するページを従来のアプリケーション・インターフェースのようにすることができます。

JavaScriptは汎用的なプログラミング言語ですが、主にWebアプリケーションで使用されます。ブラウザの実行環境の機能は、JavaScriptのキーワードでアクセスでき、目的の操作を行うためのスクリプトで使用されます。例えば、 document という用語は、JavaScriptのコードの中で、そのJavaScriptのコードに関連するHTMLドキュメントを指すために使われます。JavaScript言語の文脈では、 document は、HTMLドキュメント上の任意の要素から情報を取得するために使用できるプロパティやメソッドを持つ グローバルオブジェクト です。さらに重要なことは、 document オブジェクトを使ってその要素を変更し、JavaScriptで書かれたカスタムアクションに関連付けることができるということです。

Web技術をベースにしたクライアントアプリケーションは、互換性のあるWebブラウザがあればどんなデバイスでも動作するため、マルチプラットフォームに対応しています。

しかし、ブラウザに限定されることで、ネイティブアプリケーションに比べてWebアプリケーションには制限があります。ブラウザが仲介することで、より高度なプログラミングが可能になり、セキュリティも向上しますが、その反面、処理能力やメモリ消費量が増大します。

開発者は、ブラウザにさらなる機能を提供したり、JavaScriptアプリケーションのパフォーマンスを向上させるために絶えず努力していますが、JavaScriptなどのスクリプトの実行には、同じハードウェアのネイティブプログラムと比較して不利になるという本質的な側面があります。

ブラウザ上で動作するJavaScriptアプリケーションのパフォーマンスを大幅に向上させる機能として、 Webアッセンブリー があります。Webアッセンブリーは、C言語のような、より効率的な低レベル言語で書かれたソースコードを生成するコンパイル済みのJavaScriptの一種です。WebAssemblyは、従来のJavaScriptで書かれたプログラムを実行する際にブラウザが行う変換の多くを避けることができるため、主にプロセッサ負荷の高いアクティビティを高速化することができます。

アプリケーションの実装内容にかかわらず、すべてのHTMLコード、CSS、JavaScript、マルチメディアファイルは、まずサーバから取得する必要があります。ブラウザはこれらのファイルをインターネットのページと同じように、つまり、ブラウザがアクセスするアドレスで取得します。

WebアプリケーションのインターフェイスとなるWebページは、通常のHTMLドキュメントと同様に、付加的な動作を行います。従来のページでは、ユーザーはリンクをクリックすると別のページに移動します。Webアプリケーションは、ブラウザのウィンドウに新しいページをロードすることなく、ユーザーのイベントに応答することができます。このようなHTMLページの標準的な動作の変更は、JavaScriptのプログラミングによって行われます。

例えば、Webメールクライアントは、ページを離れることなくメッセージを表示したり、メッセージフォルダを切り替えたりすることができます。これを可能にしているのは、クライアントがJavaScriptを使ってユーザーのアクションに反応し、サーバに適切なリクエストをするためです。ユーザーが受信箱内のメッセージの件名をクリックすると、このイベントに関連付けられたJavaScriptコードが、そのメッセージの内容をサーバにリクエストします（対応するAPI呼び出しを使用）。クライアントが応答を受け取るとすぐに、ブラウザは同じページの適切な部分にメッセージを表示します。Webメールクライアントによって戦略は異なるかもしれませんが、どのクライアントもこの原理は同じです。

したがって、サーバは、クライアントを構成するファイルをブラウザに提供するだけでなく、Webメールクライアントが特定のメッセージの内容を要求するときのようなリクエストを処理できなければなりません。クライアントが行うすべてのリクエストには、サーバが応答するための手順があらかじめ定義されています。サーバのAPIでは、リクエストがどの手順を参照しているかを識別するためのさまざまなメソッドを定義できます。最も一般的な方法は次のとおりです。

リクエストの目的や、開発者が考慮するその他の基準によっては、ある方法が他の方法よりも適している場合があります。一般的に、Webアプリケーションでは、それぞれの状況に応じて、複数の方法を組み合わせて使用します。

Representational State Transfer （REST）パラダイムは、HTTPの基本的なメソッドをベースにしているため、Webアプリケーションの通信に広く利用されています。HTTPリクエストのヘッダーは、実行すべき基本的な操作を定義するキーワードで始まります。 GET 、 POST 、 PUT 、 DELETE などの基本的な操作を定義するキーワードで始まり、その操作が適用される対応するURLが示されます。アプリケーションがより具体的な操作を必要とし、要求された操作についてより詳細な説明を必要とする場合は、GraphQLプロトコルがより適切な選択肢となるでしょう。

クライアント/サーバモデルを使用して開発されたアプリケーションは、通信が不安定になることがあります。このため、クライアントアプリケーションは、常に効率的なデータ転送戦略を採用し、一貫性を保ちつつ、ユーザーエクスペリエンス（UX）を損なわないようにする必要があります。

ApacheやNGINXなどのHTTPサーバは、通常、アプリケーションのニーズを満たすために特定の設定変更を必要とします。従来のHTTPサーバは、デフォルトでは、リクエストで示されたパスを、ローカルファイルシステム上のファイルに直接関連付けます。例えば、WebサイトのHTTPサーバがHTMLファイルを /srv/www ディレクトリに置いている場合、パス /en/about.html を指定したリクエストは、ファイル　/srv/www/en/about.html が存在すれば、その内容をレスポンスとして受け取ります。より洗練されたWebサイト、特にWebアプリケーションでは、さまざまなタイプのリクエストに対してカスタマイズされた処理が求められます。このシナリオでは、アプリケーションの実装の一部として、アプリケーションの要件を満たすためにHTTPサーバの設定を変更します。

あるいは、HTTPリクエストの管理とアプリケーションコードの実装を一元化し、開発者がプラットフォームの詳細よりもアプリケーションの目的に集中できるようにしたフレームワークもあります。例えば、Node.jsのためのExpressフレームワークは、リクエストのマッピングとそれに対応するプログラミングをすべてJavaScriptで実装しています。通常、クライアントのプログラミングはJavaScriptで行われるため、コードメンテナンスの観点から、クライアントとサーバで同じ言語を使用することを良しとする開発者は多いです。その他、フレームワークや従来のHTTPサーバでサーバ側の実装によく使われる言語としては、PHP、Python、Ruby、Java、C#などがあります。

クライアントが受信または要求したデータをサーバにどのように保存するかは、開発チームの判断に委ねられていますが、ほとんどの場合に適用される一般的なガイドラインがあります。静的コンテンツ（画像、JavaScript、CSSなどの短期的に変化しないコード）は、従来のファイルとして、サーバのファイルシステムに保存するか、 コンテンツ配信ネットワーク （CDN：content delivery network）に分散して保存するのが便利です。一方、Webメールアプリケーションの電子メールメッセージ、ショッピングアプリケーションの商品情報、トランザクションログなど、その他のコンテンツは、 データベース管理システム （DBMS）に保存するのが便利です。

最も伝統的なタイプのデータベース管理システムは、 リレーショナルデータベース です。このデータベースでは、アプリケーションの設計者がデータテーブルと、各テーブルが受け入れる入力フォーマットを定義します。データベース内の一連のテーブルには、アプリケーションが消費・生成するすべての動的データが含まれます。例えば、ショッピングアプリでは、ストア内の各商品の詳細を記載したエントリを含むテーブルと、ユーザーが購入したアイテムを記録するテーブルを持つことができます。購入した商品のテーブルには、商品テーブルのエントリへの参照が含まれており、テーブル間のリレーションが作成されています。この方法は、データの保存とアクセスを最適化するだけでなく、データベース管理システムで採用されている言語を使用して、結合されたテーブルへの問い合わせを可能にします。最も一般的なリレーショナルデータベース言語は、SQLite、MySQL、MariaDB、PostgreSQLなどのオープンソースデータベースで採用されている SQL（Structured Query Language： "エスキューエル" または "sequel" と発音） です。

リレーショナルデータベースに代わるものとして、データに厳密な構造を必要としないデータベースの形態があります。これらのデータベースは、 non-relational databases または単に NoSQL と呼ばれています。リレーショナルデータベースと同じような機能を備えている場合もありますが、データの保存やアクセスをより柔軟に行えるようにすることに重点が置かれており、データを処理するタスクはアプリケーション自身に委ねられています。MongoDB、CouchDB、Redisなどが一般的な非リレーショナルデータベース管理システムです。