1. 僕がWEB業界に入ったときに思ったこと
nuxt.jsにふれる前に僕がWEB業界に入ったとき思ったことや、フロントエンドとバックエンドについて知ったことを話して行きたいと思います。
間違って認識しているところもあるかもしれないので、そこはご指摘して頂ければ幸いです。
1-1. 「デザイナーって何をやるの？」から始まった。
そもそも、僕がプログラムを触った時はブラウザなんて、ホームページを表示するとかしか、出来ることが限られていて、難しいことをさせるなら、WindowsプログラムでVisual C++を使っていうように思って（あるいは言われていた？）いました。
携わっていたのは業務用のアプリでしたので、お客さんと打ち合わせをして、Windowsで配置を決めて、ボタンや入力フィールドをポチポチと決めたり、必要なら少しボタンやフィールドをカスタマイズして、機能を拡張して開発していました。
そのシステムは実際に大手のレジ周りのシステムとして使われてたりしたので、デザイナーが画面をデザインしたりUIをデザインすることがありませんでした。
デザイナーは僕とは違う業界にいて、イラストとか描く人だとねって思っていました。
ただ、業務アプリの需要が少なくなり、WEB業界が盛り上がってきて、僕もこの業界にシフトした際に、デザイナーと仕事をすることになり、当初はこの人（デザイナー）たちはHTMLのコーディングをする人なのかなって思っていました。（のちにデザイナーが兼任していることもあるが、HTMLだけをやるひとはコーダーだということを知りました）
だって、ボタンとかフィールドは僕が勝手に作ってそれが採用されていた世界で、デザインがどうとか言われたことがなかったら、、、
仕事を一緒にやっているうちにデザインの凄さを知りました。
僕が設計したこんな感じのページでって、エクセルやパワーポイントで仕様書を出して、まあ、この通り、HTMLとかしてくれれば良いよって思ってたら、僕の想像以上のデザインやUIデザインを提出してくれるので、なるほど、デザイナーとはこんなことが出来るのかって感動しました（もちろん、デザイナーのすべての人がそれぐらいの能力があることはなかったですが）
1-2. フロントエンドとバックエンドって何だ？
ようやく、WEB業界に慣れてきて、当時はjavaのStrutsやSpring、PHPだったらCakePHPなんてフレームワークが全盛(Javaのエンジニアは高いので、誰でも使えるPHPに移行したなんて仕事があったりして)のころからしばらくして、フロントエンドとバックエンドという概念が表れ（もともとあったのしれないが、突然、言葉が普及したイメージがありました）
フロントエンド
PHPではCakePHPの勢いが、終わって、Laravelというフレームワークが流行りだした時代に、フロントエンドの開発出来る？と言われて、bladeのことか、javaのjspのことなのかって、なんで、フレームワークで、view側のbladeでだけ分けるんだと理解できなかったことを覚えています。
うーん、デザインとは何をする人ぞの後の、疑問が出てきました。
色々なの話を聞くと、どうやら、viewの部分をbladeではなくて、node.jsを使ってフロントのサーバーを分けて、APIで通信をするらしい。。。（厳密には下記のようなことらしい）
フロントエンド
フロントエンドとは、WebサービスやWebアプリケーションで直接ユーザーの目に触れる部分のことです。
WebサイトやWebアプリケーションなどでユーザーが文字を入力したり、ボタンをクリックしたりする部分や、バックエンドのソフトウエアと直接やり取りをする部分のことを指します。
クライアントサイドとも呼ばれ、Webブラウザ側でプログラムを実行しています。
フロントエンドの開発で利用する言語は主に、HTMLやCSS、JavaScript、TypeScriptです。
また、最近はReactやVue.js、Next.js、Nuxt.jsなど、JavaScriptのフレームワークやライブラリを利用しての開発も増えています。
うーん、開発効率も悪く、何より、サーバーが2台になったら、サーバーが落ちたり攻撃されたりするリスクが増すのではないか？
せっかく、blade(LaravelフレームワークのMVCのview部分)という素晴らしい機能を捨てて、そんな訳のわららんことをするのか？って思っていました。
※定義上、bladeもフロントエンドの開発ですが、最近のJavaScriptのフレームワークやライブラリを利用のフロントエンドの開発をもとに話しています。
バックエンド
バックエンドはView以外のロジック部分、MVCで言えばM(モデル)、C(コントローラー)の部分になります。
DBの繋ぎ込みや計算ロジックなどの部分を主になります。（厳密には下記のようなことらしい）
バックエンド
バックエンドは、サーバーサイド（Webサーバー側）やデータベースのシステムなど、ユーザーの目に見えない部分のことです。
ユーザーが入力した内容などのデータ処理やデータベースへの保存、検索結果の出力といったことを行います。
ユーザーからは見えない後方の部分の処理を担っていることが、バックエンドと呼ばれている理由です。
バックエンドの開発で利用する言語には、JavaやJavaScript、PHP、Python、Rubyといったプログラミング言語があり、開発効率を高めるための各種フレームワークを利用して開発が行われます。
2. フロントエンドとバックエンドを分ける利点
こちらに図があったので、イメージが掴めやすいと思います。
さて、サーバーの運用リスクや開発効率を考慮しても、以下の利点があるからフロントエンドとバックエンドを分けるみたいです。
-
柔軟なスケーリングが可能
最近はAWSなどのサービスで、ロードバランサを利用してサーバーのスケールアウトすることを前提にサービスを組みます。
その際に、例えばDBへのアクセスが遅いなど、問題がある場合はバックエンドをスケールアウトする。UI部分の表示が遅い場合などはフロントエンドをスケールアウトすることで柔軟なスケールリングが可能です。
下記は構成の図があったので、
http://itdoc.hitachi.co.jp/manuals/link/cosmi_v0870/APGA/EU010052.HTM -
バックエンドの共有化をしてフロントエンドのマイクロサービス化
APIのやりとりにより、バックエンドとフロントエンドが完全に分かれるので、フロントエンドはWEBブラウザだけでなく、スマホアプリ、IOTなどの色々なフロントのサービスに連結が可能
マイクロサービスとモノリス
https://codezine.jp/article/detail/11055
モノリスは2001年宇宙の旅とか、エヴァンゲリオンのゼーレのモノリスとは違うのかな？
-
リッチなUI表現
ajaxでの表示やリッチな表現をする際に、vuetify(Vue.jsのフレームワーク)などを利用することによりモダンなUIが可能 -
かっこいい
単なるWEBエンジニアよりも、フロントエンドエンジニア、バックエンドエンジニア、フルスタックエンジニアなどの甘美な響きにドヤ顔が出来る！
3. SPAとSSR
ようやく、一通りに僕が疑問に思っていて、腹落ちしたことを話したので、みんなも同じ疑問に思っていたのであれば、解決の力になればと思います。
さて、いよいよ、フロントエンドのフレームワークnuxt.jsについて、話そうとということになるのだが、その前に、これもちょっと理解に時間がかかったSPA「Single Page Application」とSSR「Server-side rendering」について解説します。
3-1. SPA（Single Page Application）
まずは、簡単なSPAからの解説をします。
まあ、こちらを見ればわかりますが、最初のフレームのHTMLを返して、その後にAJAXでデータの表示や変更を行います。
- メリット
フロントエンドとして、完全に分離しているので、ターゲットがブラウザでなくて、スマホアプリやIOTなどの装置でも同じ仕組みでバックエンドとの通信が出来れば、共通化が出来ます。
※これがもし、bladeだったら、View部分(Laravel + Vueという手法も選択できますが、、、)の場合はフロントエンドが独立していないため、バックエンドも作り直し、あるいは処理を分けるための大幅な改修が必要になります。
他にも、「ブラウザ側でできる処理はJavaScriptで終わらせることで、サーバとの通信量を最低限に抑えることが可能です。」なんてことがあるそうです。
- デメリット
HTMLを返して、その後にAPI通信をするので、初期のデータ取得に時間がかかる
また、、個人的に初期のローディングの時点で、最初にHTMLの枠だけ返して、データが通信中なので、フィールドが空でその数秒後にデータが表示させるので、画面が「ビクッ」となって、ちょっとかっこ悪なって感じました。
例：ようこそ「サル」さん
という会員ページの情報があった場合に、最初はようこそ「」さんと表示されており、数行後に「」 部分にサルと入るのでビクッとなるｗ
後は、HTMLを返して、jsでデータを取得表示するので、jsを実行しないクローラーにとっては、そのページがなんであるのか理解できないので、SEOに弱いなどがあげられます。
3-2. SSR（Server-side rendering）
HTMLやJSを初回にサーバーサイドでレンダリング手法なのですが、SPAでの開発を体験しないと一体、何が違うのって思ってしまいます。
開発経験がないエンジニアは「理屈は分かったけど、一体何で？」なんてことを思ってしまいます。
勘の良いエンジニアはわかるのかもしれないですが、、、
端的に言うと、SPAのデメリットを解消しているということです。
初回の表示ということも注意です。初回という認識がないと、ちんぷんかんぷんになってしまいます。
- メリット
初回にサーバーサイドで、レンダリングするために、サーバーパワーを使えるので、ユーザーのネットワーク環境・デバイスのスペックに左右されないため、 安定した配信が可能になります。
これは、SPAのデメリットで「ビクッ」となると言ったことが、初回にサーバーサイドで通信を行った結果を表示するのでビクッとならないので、かっこ良く表示されます。
レンダリングされた状態（HTMLとJSが呼ばれた状態）で表示されるので、クローラーがコンテンツの内容を理解できるのでSEOとしては良い。
後は、さっきほどのページには下記のような利点もありました。
実行結果を Cloud Front などの CDN でキャッシュ可能
SSR を行うことで、サーバーサイドでレンダリングされた結果（HTML/JS）をキャッシュさせる事ができます。
Cloud Front などの CDN を利用することで、
オリジンサーバの代わりにコンテンツを配信することができ、表示速度などのパフォーマンス向上に繋がります。
- デメリット
デメリットはあんまり、思い浮かばなかったので、先程のサイトから抜粋しました。
・SSR 実行結果を待つので表示速度にレイテンシー有(Lambda のコールドスタートと相性悪)
・SSR 対応のサーバーが必要
・SSR と SPA の処理が混在するので実装コスト増加
・実行 OS の意識が必要
最後に
さて、今度こそ、nuxt.jsについての感想をと思いましたが、力尽きたので、後半ということにして、今回はここまでにします。
最後までお読み頂いて、ありがとうございました。
僕が躓いたところで、あっ、そういうことなのかって、他の方がそうなのかって思っていただけると嬉しいですね。