最低限知るべきWebアプリケーションの仕組みと全体像

最低限知るべきWebアプリケーションの仕組みと全体像

最低限知るべきWebアプリケーションの仕組みと全体像

本記事のテーマ

エンジニアと言っても、何でもできる訳ではなく、得意不得意があることが多いです。
そのため、非エンジニアで、スタートアップを経営する方、これから起業しようとする方向けに、エンジニア採用やシステム開発に先立って最低限知っておきたいWebアプリケーションの仕組みやWebアプリケーションの全体像を解説します。

Webの歴史

インターネットとWeb

インターネットの起源は、1969年に構築されたARPANET(アーパネット)です。ARPANETは、米国内の大学や研究機関の間をつなぐネットワークとして使用されていました。
そして、1990年にスイスのCERN(セルン)という国際的な研究所で働いていたティム・バーナーズ・リー氏が、最初のブラウザとサーバを完成させました。
Webは、世界中のユーザーのブラウザ等のクライアントから、Webサーバに対して、HTTPというシンプルな通信プロトコルでアクセスできる仕組みです。

Webを一気に普及させたブラウザ

そして、Webの普及を一気に推し進めたのが、1993年にイリノイ大学の米国立スーパーコンピュータ応用研究所が公開したMosaicというブラウザです。それまでのブラウザは、文字しか取り扱えなかったところ、Mosaicは本文にインラインで画像を顕在させることができました。Mosaicは、Internet explorerやFirefoxといった現在のブラウザの源流です。

Webの仕様を統一

このような状況で、各社の実装がバラバラで運用が円滑ではありませんでした。
特に、当時、各ブラウザがHTMLとCSSを独自に拡張した結果、HTMLやCSSのレンダリング結果が大きく異なり、開発者がブラウザごとの対応を迫られる事態になっていました。
このような背景から、1994年にティム・バーナーズ・リー氏が中心となってWorld Wide Web Consortium(W3C)という団体を設立し、HTML、HTTP、URI、CSS等の標準化を行いました。
ただし、ブラウザの問題は徐々に解消されましたが、現在でもブラウザによってHTMLとCSSのレンダリング結果が異なる問題が残っています。

Webアーキテクチャの決定

2000年にロイ・フィールディング氏の博士論文により、「REST(レスト)」というWebのアーキテクチャスタイルが発表されました。当時は、Googleが検索エンジンとしてやっと一定の地位を持ち始めた頃で、現在のようなプログラムから操作可能なWebAPIは存在しませんでした。しかし、その後、GoogleやAmazonといった企業がREST形式のWebAPIを提供し始めたことで、RESTが普及しました。
RESTが普及したことで、ユーザーインターフェースがWebで統一され始め、エンドユーザーはWebだけを意識するようになりました。

RESTとは

RESTでは、例えば、Web上の記事等の情報(リソース)に対して、名前(URI)が付されています。
また、RESTは、ネットワークシステムのアーキテクチャスタイルとして有名なクライアント/サーバから派生したアーキテクチャスタイルです。クライアント/サーバとは、特定のプログラムを実行するコンピュータ(サーバ)と、ユーザーが操作するコンピュータ(クライアント)に分け、これらが相互にネットワークで接続されるアーキテクチャスタイルです。
そのため、Webでは、クライアントがサーバにリクエストを送信し、サーバがレスポンスを返します。
より具体的には、例えば、ユーザーが記事を閲覧していて、ブラウザから「次のページ」ボタンを押したとします。
この時、ブラウザは、次のページのURIにHTTPリクエストを送信し、サーバーはリクエストを受け取って、次のページの内容をレスポンスで返します。そして、ブラウザは、返ってきたレスポンスを画面にレンダリングします。

その他にも、RESTの思想には、ステートレスサーバー、キャッシュ、統一インターフェース、階層化システム、コードオンデマンドといった特徴がありますが、ここでは割愛します。

Webアプリケーションの仕組み

Webアプリケーションとは

これまでで、Webがどのように普及してきたかを記載しました。ここで、Webアプリケーションとは何なのかを解説します。Webアプリケーションとは、ChromeやFireFox等のブラウザで操作し、Webサーバー上で動作するアプリケーションのことです。
例えば、Gmail、Facebook、Twitter、YouTube等のブラウザ版は、Webアプリケーションです。
Webアプリケーションは、基本的には、インターネットに接続されている状態でなければ利用できません。
なぜなら、前述したように、ブラウザからインターネットを通じてサーバにリクエストを送信し、レスポンスを受け取る必要があるからです。

ネイティブアプリケーション

一方で、スマートフォンやPC等にインストールして利用するアプリケーションをネイティブアプリケーションと言います。
ネイティブアプリケーションは、プログラムがスマートフォンやPC等の端末にインストールされて動作するため、Webにアクセスせずに動作します。

フロントエンドとバックエンド

Webアプリケーションにおいて、フロントエンドとは、ユーザーがWebアプリケーションにアクセスした際に、目で見える部分(Webサイトのデザインや画像等)や直接操作できる部分(入力欄やボタン等)のことで、クライアントサイドとほとんど同義です。
一方で、バックエンドとは、ユーザーが見えない部分や直接操作できない部分のことで、サーバサイドとほとんど同義です。例えば、Webサイトで「保存する」ボタンを押した時に、サーバでは、ユーザーが入力した内容を処理してデータベースに保存します。

データベース

データベースとは、大量のデータを収集し、再利用しやすい形に整理した情報の集まりのことです。
データベースの管理や操作を行うときに、よく使われる言語がSQLです。SQLは、ISO(国際標準化機構)などにより標準規格化されており、MySQLやPostgreSQL、Oracle Databaseといった代表的なデータベースで利用できます。また、最近では、GoogleのFirebaseのような、SQLを使わないデータベースもよく使われます。

言語

データベースを操作する言語としてSQLという言語をご紹介しましたが、言語にも様々あります。
フロントエンドでは、一般的には、HTML、CSS、Javascriptといった言語が用いられます。
バックエンドでは、Java、Ruby、Python、その他多種多様な言語が用いられます。
また、Webアプリケーションではなく、ネイティブアプリケーションを開発するのであれば、iOSアプリではSwift、AndroidアプリではJavaやKotlinといった言語が用いられます。
このように、言語は多種多様で、それぞれの言語によって、何を開発するのが得意な言語なのかが異なります。

フレームワーク

Webアプリケーションフレームワークは、Webアプリケーションを開発するための骨組みです。
ゼロからWebアプリケーションを開発しなくても、どのアプリケーションでも共通の機能等は、ある程度フレームワークが提供してくれます。そのため、フレームワークを利用することで、圧倒的に速くプログラムが開発できます。
RubyならRuby on Rails、PythonならDjangoやFlask等、JavascriptならNuxt.jsやVue.js、React.js、Angular.js等、フレームワークも多種多様です。

ライブラリ

フレームワークは、アプリケーションの骨組みとなり、フレームワークを基盤にして、それにプログラムを追加していくイメージです。それに対して、ライブラリは、プログラムを構成する部品です。
アプリケーションに機能を追加したい場合、自分でプログラムを追加開発しなくても、既に提供されているライブラリがあればそれを使うことで、開発速度を短縮することができます。
ただし、あまりライブラリに依存してしまうと、何らかの事情でライブラリを利用することができなくなった際に、Web
アプリケーションとして機能しなくなってしまうリスクがあるため注意が必要です。
また、導入の際には、ライブラリが信頼できる提供者なのか、商用利用して良いライブラリなのかといった視点も重要です。

まとめ

今回は、Webアプリケーションの仕組みや全体像で、最低限知っておくべき内容を記載しました。
エンジニアと言っても、フロントエンドが得意なエンジニア、バックエンドが得意なエンジニア、両方できるフルスタックエンジニア、ネイティブアプリが得意なエンジニア等、得意不得意が様々あります。
エンジニアを採用する際は、何を開発したいのかに応じて開発に必要な言語やフレームワークを選定し、その技術が得意なエンジニアを採用すべきです。