自宅隔離中なのでフロントエンド事情の調査〜2021〜

2 min read

はじめに

身内にCOVID19陽性者が出たので、自宅部屋に隔離となりました。

やりたい事

自作ブログを作成したいと思います。

現在のスキル

  • Vue(最近触ってないので忘れがち。アプリ開発をしたがプロレベルでは無い)
  • JavaScript
  • HTML/CSS(見よう見真似で触っていたので基礎からいつか勉強したいと思っていた)
  • Docker(何度か活用している)

最近のフロントエンド事情

最近のフロントを調べていると、気になるワードがいくつか・・・。

https://fastcoding.jp/blog/all/info/state-of-frontend-2020-1/#no1-2

SPA vs SSR vs SSG

これら3つはアプリケーション動作の仕組みです。

それぞれの特徴

SPA(Single Page Application)の特徴・・・

初回のリクエストでサーバーはJSのビルドファイルとHTMLを返します。ブラウザ上からAPIを叩く事で、サーバーからのレスポンスをHTMLにレンダリングする形で差分を更新します。

SSR(Server Side Rendering)の特徴・・・

初回のリクエストでHTMLを返しますが、ついでにサーバー側でAPIを叩いてレンダリングまでしてくれます。2回目以降のリクエストでは、ブラウザ上からAPIを叩く事で、サーバーからのレスポンスをHTMLにレンダリングする形で差分を更新します。

SSG(Static Site Generator)の特徴・・・

アプリのビルド時にAPIからデータを取得、レンダリングを行い、HTMLを返します。データの更新毎にビルドを行うのが特徴です。CDN(Content Delivery Network)ーキャッシュサーバにHTMLの複製が保存されるため、サーバーへの負荷軽減にもつながります。

おすすめ

正直一長一短ですね。各分野を重視!と言う時に適しているのはどれか調べます。

SE0・・・[SSR] か [SSG]が良い!

むしろ[SPA]では初回のHTMLが空なので、Googleクローラーが探し当てられない可能性があります。

PWA対応・・・[SPA]が良い!

PWA対応(Progressive Web Apps)とはモバイル端末でネイティブアプリのような動作を実現でき、UX向上にどれだけ貢献できるか。

表示パフォーマンス・・・[SSG]が良い!

静的サイトの配信にとどまるため。キャッシュサーバにHTMLの複製が保存されるため、サーバーへの負荷軽減に繋がる!

セキュリティ・・・[SSG]が良い!

ビルド時に事前にHTMLを生成して、HTMLを配信するだけなので、上二つよりリスクが低いような気がします。

https://shimablogs.com/spa-ssr-ssg-difference#toc1

JAM Stack

「JavaScriptでAPIを叩いてMarkupを配信する」の略称。

ヘッドレスCMS(データ登録・更新など)+SSG(HTMLの生成)+ホスティングサービス(配信)の機能で構築可能です。

上記のSSGで「データを更新した時に毎回ビルドしなくてはならない」と記述しました。手動でやると面倒臭いですが、そんなのやる必要はありません。
データ更新が発火した場合、サーバーレスなどでビルド処理を実行してやればいいのです。データ更新+HTMLのビルド+HTMLの配信を自動で実現してくれます。(CI/CDの概念)

ただ問題点があります。

1.データ更新数が多いサービスは向きません。

データ更新のたびにビルドしますので、ビルドが追いつきません。どちらかと言うと、閲覧専用サービス(自分以外)などに向いています。例えばブログやコーポレートサイトなど・・・。

2.コンテンツ量の多いサービスは向きません。

コンテンツ・ページ数が多いとビルドが大変時間がかかります。SSGの欠点でもあります。

https://qiita.com/ozaki25/items/4075d03278d1fb51cc37

GraphQL

API用のクエリ言語とスキーマ言語で構成されたWeb API規格です。
既存対抗馬にRESTが存在します。

RESTの弱点

RESTはデータ取得の際に、必要のないデータまで取得してしまいます。処理速度の低下やメモリリークが発生しがちと言う課題がありました。

GraphQLにて何を改善?

  • 最小限のデータのみ取得
  • データ型の定義がなされている
  • HTTP構造に依存しないゆえ、複数のページに必要なデータを取得
  • パフォーマンスの向上(リクエスト-レスポンスが最小限でサーバーへの負荷軽減)

https://udemy.benesse.co.jp/development/system/graphql.html

継続的インテグレーションとデリバリー(CI/CD)

CI

開発ブランチにおける隠された課題

チームに所属するエンジニアが作業が完了した時点で、変更点をMyブランチからMasterブランチでマージしていました。しかしマージ段階でバグが残っている場合、その度に蓄積され、誰が残したバグなのかを明確にすることが煩雑だとされてきました。

継続的インテグレーションでの解決

そこでエンジニアは自分の書いたコードを⑴ビルド、⑵ローカルで単体テストを実施します。この処理を自動化することで、マージ前にバグを早期に発見して、Masterブランチの質を高めようと言う目的があります。

CD

継続的デリバリーではコード変更ののちに、ビルド・テストを実行した後に、非運用テスト環境、その後並列的なテストを受けて運用環境へデプロイされます。

https://aws.amazon.com/jp/devops/continuous-integration/

まとめ

今回は自作ブログを目標にしていますので、JAMStackを軸に勉強してみようと思います。

Discussion

ログインするとコメントできます