【Webアプリケーション初心者】Webアプリ初心者のための、大雑把な仕組み説明（WIP）

#はじめに

この記事は、Webアプリケーション初学者のための、超大雑把な仕組みの説明になります。

「ドメイン？」「API？」「アプリケーションサーバ？」「サーバサイドレンダリング？」のように、
本を読んでも、そもそもの意味が頭に入ってこない。　もうだめだ....って方向けの記事になります。

超ざっくり説明している上に、もっとここ説明した方がいいだろ！！って部分もあると思いますが、
あくまで、Webアプリケーション初学者が、FE あるいは　BE側の作業をやっていく上で、最低限知っておくべき
Webアプリケーションの知識という観点なので、悪しからず。
※図の作成は間に合わなかったので、今度付け足します。


#目次
　1.Webアプリケーションって？
　2.構成する要素（登場人物）の確認
　3.それぞれの要素について
　4.SSRとSPA


#1.Webアプリケーションって？

その名の通り「Webのアプリケーションです！」と言っても、抽象的すぎてイメージ湧かないですね。
このタイミングでは、必要知識が未だないという点もあるので、
相対する「ネイティブアプリ」と比較して、説明をしようと思います。

#####ネイティブアプリ
ネイティブアプリとは、一般的にはスマートフォン・PCにインストールされている
アプリケーションというイメージで良いです。
Androidのアプリなら、Google Playから。
iOSのアプリなら、App Storeから、「モンスト」だったり、「体重管理アプリ」
はたまた、「Google Map」、「Yahoo!JAPANアプリ」等をインストールできると思います。

上記のようなアプリは、インストールを必要とする反面
インストールしてしまえば、いつでもOS上で起動できるアプリケーションだと思います。
ネットワークに繋がっていなくても、アプリケーションの起動は行えますし、サーバとの通信が不要なものは
いつでもどこでも起動して、使えます。
このような、「インストールは必要だけど、アプリケーションの実体を端末に入れてしまえば、起動・動作がいつでもできるアプリケーション」を
ネイティブアプリと捉えていいかと思います。


#####Webアプリケーション
ネイティブアプリに対して、Webアプリケーションは 
　・ネットワーク環境が必ず必要
　・画面表示を担うのは、Webブラウザ（IE,Chrome,safari...etc)になります。

....これでは、あまりに抽象的すぎるので、もう少し具体的に説明していきましょう。
Webアプリケーションを知るには、もう少しWebブラウザをはじめとした　ネットワーク上の登場人物を
理解しておく必要があるので、
「Webアプリケーション全体の構成要素」を確認していきましょう。


#2.構成する要素（登場人物）の確認　（図、用意中）

Webアプリケーションの中に出てくる、登場人物を分類わけして表現していきましょう。
※ここでは一旦SSR(サーバサイドレンダリング)パターンで、解説します。
 後から、SPA（シングルページアプリケーション）についても追記します。


◽️一般のユーザの方々
　・Webブラウザ


◽️一般ユーザ（ブラウザ）　と　サーバサイドをつなぐ要素（インターネットの層）
　・DNS　（図は右記がわかりやすい：https://webtan.impress.co.jp/e/2011/11/25/11551）
　・HTTP通信／HTTPS通信　
　　|-HTTPメソッド
　　|-リクエストヘッダ／ボディ
　　|-レスポンスステータスコード／ボディ


◽️サーバサイド（いわゆるBEエンジニアが作るもの）
　（htmlテンプレートは、FEエンジニア）
　・HTMLファイル（HTMLテンプレート）
　・Webサーバ
　・Webアプリケーションサーバ


　
#3.それぞれの要素について
---
#####一般ユーザ側の登場人物
---
#####Webブラウザ
一般的には、みなさんがググる時に使ったりしている、
「chrome」、「IE」、「edge」、「firefox」...etcのような、
Webページを閲覧しているツールのことです。

今回知って欲しいのは、Webブラウザは一体何ができるツールなのか？という点です。

Webブラウザは、大きく分けると２つの機能を持っています。
①HTMLのファイル（および CSS や　javascript）を解析して、画面描画する機能。
②HTMLファイルを取得するために、Webサーバに対してHTTPの通信を行う機能。（SPAの場合は、若干表現が誤ってるが、一旦現段階の説明のため）

①から分かることは、
皆さんがいつもWebで閲覧しているサイトの描画は、　どこかからHTMLファイルを取得して、それを描画しているということ。

②から分かることは、
画面描画するためのHTMLファイルを、Webサーバから取得する通信を担っているということ。
（みなさんが、googleのtopページに行く場合は、　URLに　「https://www.google.com/」と打ち込んでるはずですが、
　これも同じくWebサーバへの通信を行って、　HTMLファイルを取得し、　画面描画している　といった動きになります）

これらのブラウザの動きを軸に、HTMLファイル取得までの流れ（Webアプリケーション）の解説をしていきます。

---
#####一般ユーザ（ブラウザ）　と　サーバサイドをつなぐ要素（インターネットの層）
---
#####DNS
DNS・・・ドメインネームシステムの略です。
いや、なんのシステムやねん。って話なのですが。笑

ここを軽く説明していきますorz
※今回、IPv4,IPv6,グローバルIP、プライベートIP、固定IP周りに関しては触れず、
　あくまで、対象のサーバが XXX.XXX.XXX.XXXの固定IPアドレスを持ってると仮定して説明します。

前提として知っておかなければならないのは以下の1つ
　・インターネット上で、通信を行う端末には、必ずIPアドレスが割り当てられている（みなさんのPCもそうだし、　Webサーバもそう）

---

はい、前段はここまでとして。

ざっくり言うと、ドメインとはIPアドレスを人用に分かりやすく文字列にしたもの　という認識で良いと思う。

上記にも書いたように、全てのWebサーバ（いわゆる　googleのサーバや　amazonのサーバ等　あらゆるWebサーバ）は
IPアドレスを持っています。
なので、Webブラウザで http://XXX.XXX.XXX.XXX　と打つと、当然該当のIPのWebサーバに通信ができます。
この時、このIPがWebサーバなのならば、HTMLファイルを返してくれるでしょう。

ただ、普段IPアドレス（数字だけ）で、URL書いたりしないですよね？
kakaku.com だったり www.google.com　のように、文字列で表現していますよね。
これこそが、IPアドレスを代替してくれる文字列＝ドメインです。

では、ブラウザで「http://XXX.XXX.XXX.XXX」に接続した場合、どんな動きをするのか？
以下のように、分散型のサーバの仕組みを使って、IPアドレスを探しにいきます。

https://webtan.impress.co.jp/e/2011/11/25/11551を参照。

この分散型のサーバで構成された、ドメインからIPアドレスを探しあてる仕組みを　DNSと呼び、
それぞれのサーバのことをDNSサーバと言います。

図からも分かるように、
DNSサーバには　IPとドメインの紐つけが登録されていたり、
ドメインのDNSサーバ名が記載されていたりします。
※元々はhostsファイルは、この仕組みの前段だったことや、
 DNSレコードの、”Aレコード”、"CNAME"等についてはいずれ）

今回は、ドメインから、webサーバ（IPアドレス）にたどり着くことができるよ、が分かればOK。


#####HTTP通信／HTTPS通信
これは、ブラウザ↔︎Webサーバ間の通信方式の総称のことです。
この通信方式の中での、細かな仕様はこの後説明します。

ここでは、
　・HTTP通信・・・通常の通信
　・HTTPS通信・・・暗号化した通信
であることを意識しておいてください。　今回はここだけ理解でOK。

余談ですが、
数年前から、HTTPS通信であることが、googleの検索上位ヒット（SEO)の一つの評価にもなっていることから、
HTTPS通信にすることが推奨されています。
が、これを満たすには、　SSLサーバ証明書　を取得する必要があリます。　
例えば以下のような感じで、証明書のレベル具合によって値段も変わってきます。
https://jp.globalsign.com/service/ssl/products_price/


#####HTTPメソッド（HTTP通信／HTTPS通信）
HTTP通信としては、以下のようなメソッドで通信ができます。
https://developer.mozilla.org/ja/docs/Web/HTTP/Methods

一般的に、みなさんが単純にWebで検索をしたり、URL欄にURLをうって画面表示している時は、
GETメソッドで通信（リクエスト）を飛ばしています。
Webサーバ側は、GETメソッドの時は、こんなHTMLファイルを返すんだよ〜という機能を実装しておくことで、
ユーザ側にHTMLを返すことができます。


ここで注意して欲しいのは、
POSTや、PUT、PATCHのように、　”部分更新（更新）”　や　”全体の置き換え（登録）”を意識したメソッド達がいますが、
これらはあくまで、上記のような思想で利用してくださいという思想です。

例えば、PATCHは”部分更新”といった意味合いがイメージですが、
ブラウザ＝＞Webサーバに　PATCHで通信が飛んできたときに、データを全部削除してね〜という実装をWebサーバにしておけば、
PATCHでデータを削除することもできます。

ここで言いたいことは、それぞれのHTTPメソッドに対応した処理を作成するのは、
Webサーバ側と言うことです。　どんなにブラウザから、PATCHです〜　PUTです〜という通信をWebサーバに投げても、
Webサーバ側がHTTPメソッドの対応する、適した実装をしておかなければダメです。
（BE側のエンジニアは、このHTTPメソッドと、　実際の機能の紐つけを適当にやらないように！）


#####リクエストヘッダ／ボディ
HTTP通信の中で、ブラウザ＝＞Webサーバに上記のHTTPメソッドで通信する際、
リクエストヘッダ／ボディ　と言うものが通信の中で飛んでいます。

webサーバ側は、このデータを元に登録処理等をしていきます。

リクエストヘッダには、基本的に追加情報（付加情報）が含まれています。
いろんなものが送れますが、代表的なものでいくと以下のようなものです、
Accept・・・Webサーバから返却される際に受け取れる形式
　例）text/html　

リクエストボディには、Webサーバに送る情報そのものです。
例えば、Webブラウザの画面で”名前欄”という入力フォームがあって、
送信ボタンを押した際に、名前を登録する昨日だったとしましょう。

この場合、送信ボタンを押された際には、POSTメソッドで通信が発生し
その時のリクエストボディの中身には、　名前欄に入力した　値　が入っているイメージです。
※「POSTで飛んできた時、リクエストボディ内の値を登録する」という機能を　Webサーバに用意しておけば登録が可能です。
　そして「POSTで飛んできた時、リクエストボディ内の値を登録する」　これこそが、APIそのものになります。


#####レスポンスステータスコード／ボディ
こちらは、Webサーバでの処理が終わった後、
Webサーバから、ブラウザに対して情報を返す時の情報群になります。

レスポンスステータスコードと言うのは、処理の結果を体系的にコードで表したものです。
これもHTTPメソッドと同じように、デタラメなもので返すことも可能ですが、
返すべきコードで返すようにしましょう。
（これに関してもBEエンジニアは、迷った際はプロジェクト方針と、フロント側でのエラーハンドリング方針も意識しておくこと）

レスポンスボディは、それこそ今回の場合はHTMLファイルそのものになります。
ブラウザからリクエストが飛んできて、　それに対する返却値が　HTMLファイルとなる。　この、HTMLファイルをレスポンスボディで返しています。



はい。ちょっと説明の合間合間に、サーバ側の話まで及んでしまっていましたが、
最後は、サーバサイド側の説明になります。

---
#####サーバサイド（いわゆるBEエンジニアが作るもの）

---

#####HTMLファイル
これは、HTMLのフォーマットに則って作られたファイルのこと。
このファイルをブラウザに読み込ませることで、画面描画が可能になります。

このHTMLファイルを作成したり、CSS等でデザイン調整を行うのは、
FEエンジニアの仕事となります。

thymeleaf(JSPもかな？)の場合は、このHTMLの記述の中に、
動的な値を記述することができ、その動的な値に　サーバサイドプログラムで作った値を
連携することで、　プログラムに則った、動的な画面を作成することが可能です。
この、「動的な値を記述する」など、HTMLテンプレートに手を加えていく部分は、
一般的にはBEエンジニアの仕事になるかと思います。


#####Webサーバ
ここが一番間違われやすいもの。
よくTomcat(WEBアプリケーションサーバ）と混同されがちで、初学者を惑わせる原因になると思ってます。
ここは言葉をきちんと使い分けていきましょう。

Webサーバとは何ぞや？なのですが、簡単に言ってしまうと
これまでに説明してきた、ブラウザからのHTTP通信を受けることのできるサーバのことです。

んー。。しっくりこないかもしれません。
表現を変えましょう。

ブラウザ　＝＞　あなたのお使いのPC（IP）に　HTTP通信は行えますか？
　答えはNOです。何故ならば、Webサーバじゃないから。

じゃあ、どうやったら、Webサーバになれるのか？　どうやったらHTTP通信を受けることができるようになるのか？
答えは、「Webサーバになる為の　ソフトウェアをコンピュータにインストールする」です。
ここで出てくる、ソフトウェアがかの有名な「Apache (Apache HTTP Server）」　や　「nginx」になります。
これをインストールすることで、初めてHTTP通信を受け取る　Webサーバになることができます。

結果としては、「Webサーバとは、　Webサーバ用ソフトウェアをインストールして、稼働しているコンピュータ」のことです。



#####Webアプリケーションサーバ
Webサーバの中に、構築されているのが Webアプリケーションサーバという認識で良いです。

Webサーバが、単純にHTTP通信として、リクエストを受け取るのに対して、
それぞれのHTTPメソッドに応じたサーバサイド側のプログラム（API）を作っておいて、
プログラミング言語に対応した処理を行うのが、Webアプリケーションサーバになります。
有名なもので行くと、JavaのWebアプリケーションサーバ「Apache Tomcat」です。

あれ？Javaのwebアプリケーションサーバがあるということは....
そうです。　他の言語用のwebアプリケーションサーバもあります。（私は使ったことないですが）

例えば、Webサーバで説明した、「nginx」に対応した、　Python、Go、Perl、Ruby、PHP等の言語で利用できる
Webアプリケーションサーバ「NGINX Unit」があったりします。


はい、図ができてないので、ホワイトボードに書きながら説明するしかないですが。笑
一旦Webアプリケーション全体像のお話はできたかと思います。

最後に少しだけ、SPAの話をしましょう。


#4.SSRとSPA
ここまで、SSR（サーバサイドレンダリング）を軸に話をしましたが、
SPAについても話をしておきましょう。


#####SSR
ここまで説明してきたように、
ブラウザから、HTTP通信（GETとかPOSTとか）をWebサーバに送りつけることで、
それぞれのアプリケーションサーバの中で処理を行い、　最終的にHTMLファイルを返却してもらい、画面描画する流れでした。

はい、何か問題でも？といったところかと思います。

サーバ側に処理が集中するものの、ロジック等の処理全て含めてサーバ側で行うので、
処理自体は高速に行えて、素早くhtmlファイルを作成しブラウザに返すことができます。
なので、ユーザの端末がゴミスペックだろうが、高スペックだろうが、描画自体にあまり差異が出ることはありません。

ただ一つ古臭いなと思う点があります。
ページに接続した時、更新ボタンを押した時、次へボタンを押した時、カテゴリを変えた時....それぞれ
Webページで何らかのアクションを起こすたびに、ページが再描画されます。（一瞬画面が真っ白になったりしますよね）
いやぁ、ページ遷移（再描画もせず）せず、実現できたらモダンだなと。。。

これを実現するのがSPAです。


#####SPA　（ここ図がないとキツイので、絶対追加）
これまで、サーバサイド側は、「HTMLを返す！」といい続けましたが、SPAでは異なります。
これまで同様、各画面の初期描画時（例えば、ホーム画面、商品選択画面...etc)は、htmlを返します。

しかし異なる点はここから。
例えば、カテゴリをAからBに変更したとしましょう。（図がないときついな）
今表示している画面に、色々なコンテンツがあるとして、
今回描画し直したいのは、カテゴリの部分だけである。といった場合に、SSRでは他コンテンツ含めて全ての情報をもう一度取得し直して、
画面描画を行います。
それに対し、SPAではカテゴリの情報だけを返してくれる機能をサーバサイド側に作っておき、
画面でカテゴリを変更された場合は、javascriptでサーバサイドにカテゴリ情報を取得する機能を呼び出します。
この時、データのレスポンスは、「HTML」ではなく、「jsonやxml」で受け取ることで、　画面側の実装で部分的なコンテンツの描画し直しができます。

これがSPAの良さです。
と言いたいところですが、全く言いたいことが表現できてないので書き直します。笑



一旦今日はここまで。