こんにちは。
MDC2021アドベントカレンダー10日目の記事にて、実際に作ってみる記事はまた後日書きますといってしまったので、そのお約束の記事です。
どちらかというとこちらは、モノづくりというところに寄っており、本論に近い形になっているので、
序論である上記の記事を読んでいない方はそちらを先に読んでいただけると若干理解が早いかもです。
では今回もよろしくお願いいたします。
想定読破時間：10分
（比較的私の記事はポエムが多いですね。ご了承いただければと思います。だってポエムだもの。）
全体論
昔（昔といっても10～15年ぐらい前？）は、基本的にはクライアントサイド（端末とか）は貧弱なものであり、
ウェブサービスとかは（基本的にクライアントサイドよりはパワーのある）サーバ側で処理を行い、
その処理の結果としてHTML/CSS/(Javascript)を生成して、クライアント側はそれを表示するだけ、といった構成がほとんどだったと思います。
※ここでいうJavascriptは現在の非同期通信等の重い処理ではなく、画面に若干の動きを付けるようなものでありました。
時代は進み、ナンバリングが3から始まったiPhoneもいつの間にか13まで出ている現代において、クライアントサイドもJavascriptとともに飛躍的な進化を遂げています。
（もちろんデバイス側がつよつよになっている、というのもあるとは思いますが、それと同じぐらい、Javascriptそのものの進化も大きいと思います）
また、クライアントに処理を寄せるということは、サーバ側での処理がもはや不要になるということにもつながります。
つまり、サーバ側はもはやデータを保有するぐらいしか役割がなくなってしまう構成もとりえるようになった、ということです。
※そうはいっても、セキュリティ的な問題や性能的な問題で全部が全部このクライアント側に寄せた構成になっているかというとそういうわけではないと思います。
これらの意味するのは、今ウェブサービスを提供しようとしたときにはその主の処理をだれが実施するかによって構成を分けることができます。
-
パターン1：サーバ構成
- 昔ながらの構成。サーバ側で主処理を行う。（クライアント側は画面の描画が主）
- サーバ側で処理が完結するため、秘匿情報をどう扱おうか？などのセキュリティ的な部分は考えなくていい場合があります。（勿論攻撃の対象にされるとかはありますが、普段の開発としてはサーバ側で完結しているというのは一つのメリットです）
- ただし、処理をするサーバが存在しなくてはいけないので、その用意や維持に負荷がかかります。（サーバのトータル維持費も結構馬鹿になりません。）
-
パターン2：サーバレス構成
- 比較的新しい構成であり、クライアント側で主処理を行う。（サーバ側はデータの格納ぐらいしか役割がない）
- メインの処理はJavasciptとなり、クライアント側で処理がされるため、従来のようなしっかりとしたサーバを構築・運用する必要がない。
- ただし、データをどこで保持するか？など、セキュリティの問題を扱うのが比較的難しい。
当然、サーバ構成とサーバレス構成はメリットデメリットがひっくり返ることとなります。
が、サーバレス構成の一番大きいところはサービスの開発者が、サーバ構築などという余計な事に気を使う必要がない（あるいは薄い）ということです。
Webアプリケーションを作るときの登竜門はおそらくHTML/CSSだと思います。これがまさに画面を構成する要素となるからです。
その次に勉強するべきは何か？となるとやはり動的なデータをやり取りしたい、ということでJavascriptにつながることが多いです。
このケースにおいては、JavaやPHP、Pythonといった言語を勉強するというモチベーションに直結することは（残念ながら）ないのかなと思います。
いえ、昔はこのあたりの言語を勉強しないと動的なデータの更新はできなかったのですが、最近はこれらを意識しなくてもよくなった、というのがいいところでもあり、少し残念なところでもあるなと感じます。
（残念、と言っているのはもはやサーバレス構成に慣れすぎてしまうと、本来存在しているべきサーバの存在に本当に気づけなくなってしまうと思うんですよね。）
個人的には、サーバレス構成というものが出てきて、エンジニアの敷居（特に初期導入の敷居）は下がったかなと思います。
これ自体は歓迎するべきことであり、どんどん技術者が出てくるのはうれしいことだと思うのですが、気が向いたらサーバというものに目を向けてみていただけると、
エンジニアとしての深みが出てとても良いと思いますので、たまには思い出してあげてください。
というわけで今回はこの2パターンについて少し具体的に見ていこうと思います。
こらむ：SPA/MPA
HTMLファイルを書いたことがある人はわかると思うのですが、1ページにつき、1HTMLファイルという構成になっていると思います。
で、< a >タグみたいなので、違うファイルにリンクさせてクリックすると別のページに富んだように見える、というイメージがあると思います。
なので、そのページごとにHTMLファイルを用意するので、Multi Page Applicationと呼ぶことがあります。
これは、以前はこの方法しかなかったので、こんな言い方はしなかったと思うんですが、Javascriptが出てきてSPAという考え方が出てきたので、それの対応としてこの言葉が生まれたんだと思っています。
Javascriptは（というか最近のSPAフレームワークは、といったほうがいいかもですが）1つのファイルを読み込んで処理がされます。
（開発するときは開発しやすいように複数jsファイルとして開発はしていくのですが、最終的にアプリケーションとしてリリースするときには1ファイルに固められます。）
したがって、複数ファイルを利用せず、単一ファイルのみで提供されるため、Single Page Applicationと呼ばれるようになったんですね。
この辺りは、師匠であるozaki25さんの記事がハイパーわかりやすいので、是非見てみてください。
簡単に言うと、SPAはクリックしたときにページが移った（ように見せている、Javascriptで画面を切り替えている）といった仕組みになっています。
どちらがいいとか悪いとかいう話ではなくて、この辺りはこの特性によって両方ともを理解しておかないと、思わぬところで躓いたりするので注意だなと思います。
（私自身、最初SPAが全く理解できてなくて進めており、それがゆえにエラー対応できなかったことがよくありました。）
パターン1：サーバ構成
さてそれでは、それぞれの構成について詳しく見ていくことにしましょう。
ここではその処理の層について「クライアント層」「ミドル層」「バックエンド層」の3分割して考えていくことにします。
何を言っているかわからない、ぴんと来ないという方は前回の記事を見てみてください。
- フロントエンド層
- 特にクライアント側での処理は考える必要がないです。（すべてサーバ側でファイルを作って渡すだけなので）
- ミドル層（データ連携）
- ここも特に意識をする必要がないです。しいて言うなら、アプリケーションからDBに対してちゃんとアクセスができているか、というところぐらいです。
- バックエンド層
- サーバ構成において、このバックエンド層にすべての処理が集約されることになります。
- 以前は、LAMP構成といって、Linux+Apache+MySQL+PHPという要素で構成されるのが多かったかと思います。
- Linux：サーバが動くOS全般のことを指し、例えばUbuntuとかCentOSとかのことです。Windowsとかのイメージです。
- Apache：Webサーバという言い方をしますが、実際にクライアントからアクセスされ、必要に応じてPHPとかの処理層に処理を中継します。
- MySQL：データを格納しておくソフトウェアです。最近はMariaDBがとってかわられているそうですね。
- PHP：実際に動的にページを生成する処理をコードで書いていきます。例えば"echo date('Y/m/d');"って書くと今日の日付が出力される、的な感じです。
このあたり、気にある方は以下の書籍とかが参考になりましたので、よろしければ。
（内容としては、RaspberryPiをサーバとして構築し、このあたりのWebサービス系を利用してみるといった感じです。）
やはりハードルになるのはサーバを立てるという部分になるかと思いますが、このあたりも最近はCloud9が出てきたりで若干楽になったかなという印象はあります。
が、やはりサーバを運用するというところに抵抗感がある人は少なくないんじゃないかなぁと思いますね。
覚えておく必要があるのは、PHPやPythonとかを勉強してもそれをどこで動かすのか？という問題はついて回りますので、
そのあたりは理解したうえで進められるとよいと思います。
パターン2：サーバレス構成
さて、続いてはサーバレス構成です。最近はやっている構成ではあると思います。（今でも印象に残っているのは「アプリ開発者はアプリの開発に興味はあるが、サーバの保守には興味がない」という言葉です。確かにそうかもなぁとか思いました。）
サーバ構成を見た時のように分解してみてみましょう。
- フロントエンド層
- ここが肝です。主としてJavascriptを利用して処理を書いていきます。フレームワークとしてはReact/Vue.js/Angularとかが有名ですね
- 実際の画面をここで作ることになりますので、データのやり取りとは分離されることも多いと思います。
- ミドル層（データ連携）
- フロントエンド層が利用するデータをバックエンドとやり取りする（処理の）層です。ここは一定の処理となることが多いです。RESTとかが利用されることが多いです。
- バックエンド層
- もはやデータを保存しておくぐらいしか役割がない層になります。上記の通りミドル層からRESTで通信処理を行います。
フロントエンド層とミドル層に分けていますが、結局全部Javascriptで記載し、クライアント側で処理をするということに変わりはありません。
バックエンド層については、サーバレス構成ということで、AWSでいうとAPIGatewayやLambda,DynamoDB等が利用されます。(要はサーバは管理しないということ)
また、フロントエンド層もSPAという意味では、上記の3フレームワークが利用されることが多いですが、そこまでの知識がない、といったケースでは、
MPA構成とし、HTMLやCSSを頑張って駆使してフロントエンドの画面を作り、jQueryを使ってバックエンドとデータをやり取りするミドル層を作るケースもあると思います。
詳細についてはググれば出てくると思うので、特にここで説明することはしませんが、大きくフロントエンド層、ミドル層、バックエンド層という役割について覚えておいていただけるとよいかなと思います。
（上記ではAWSとしてお話をしましたが、別にFirebaseとなることもあると思うので。）
最後に
最近は技術の進歩で、アプリの開発業務に集中することができるようになり、
だからこそ、それ以外の部分はブラックボックス化がすごいスピードで進んでいるように思えます。
繰り返しますが、ブラックボックス化そのものについては、多くの人にチャンスが生まれているということだと思うので、悪いわけでは全くないと思うのですが、
どのサービスにおいても、必ず上記の考え方（フロント・ミドル・バック）は必要になってくるものだと思います。
例え、自身がほかの部分を担当することがなかったとしても、そこの理解が少しでもあるかないかは大きな差になると思います。
（例えば、フロントエンド技術者が、データの構造について全く無関心である場合、そこからスマートなサービスが生まれるとは思えません。）
勿論自身のコアスキルを磨いていくのは大事なことだと思いますが、その周辺知識もつけていけるとスマートなエンジニアになれるのではないかなと思います。
小時間、ポエムにお付き合いいただきましてありがとうございました。
（さすがに図も何もないのはわかりづら過ぎるので、イラストとか追記しようと思います。いつか・・・）