SSRとJSとフレームワークの技術選定 #JavaScript

最近社内でJS最新技術を使ってみよう！という流れになったので、
JSのフレームワークを調査してみました。

また、よく耳にするSSRという単語がフレームワーク調査で頻出したので合わせて調べました。

ReactとVue

世界シェアだとReactがダントツの様子。
https://note.com/erukiti/n/na654ad7bd9bb
　→比較基準で賛否両論あるらしいが個人的には外れていないと思う。

身の周りでもVueを採用する話をよく聞くが、これだけ数字出ているのにReactの名前が出てこないのが不思議。

なんとなくReduxでツライみたいな空気があったような気がしており、丁度そのころにVueが来て刺さった気がしがしなくもない。
その後２０１９年にReactHooksが来てイベント周りがガラッと変わってかなり使いやすくなったらしいのと、TypeScriptの相性からReactなんとなく使いたいなと思う。

SSR

SSRとはなにか

サーバーサイドレンダリングの話になった時、
NuxtだのExpressだのと名前が上がり混乱したので一旦整理。

素のVueもしくはReact
- ユーザー側JSでレンダリング。読み込みに時間がかかり、Botが食わない可能性あり。
SSRを使用
- リクエスト時にHTMLを組んでレスポンスを返す。動的な処理はユーザー側JSで再レンダ。レスポンスにHTMLを返すのでBotが構造を食える。

SSRを利用する時、一般的にこの構成になる。

フロントエンド（ユーザー側JS）
SSRを行うSSR領域（SSR鯖）
リソースを提供するバックエンドAPI（API鯖）

リクエスト時は１→２→３→２→１といった具合に経由する。

SSR鯖では、たいていフロントエンドのライブラリ（VueとかReactとか）をサーバーで動かしてHTMLを構築し、それをフロントエンドに返す。
なのでライブラリがそのまま動くNode.jsのWebフレームワークであるExpressの名前が頻出する模様。

Next.jsやNuxt.jsがSSR対応、という意味が今までよくわかっていなかったが、
要はExpress（か類似のなにか）を内蔵している、もしくは管理する何かが内蔵されており、
そこでSSRすることを指しているらしい。

SSRのメリット・デメリット

メリット

SSRのメリットはここがわかりやすい。（ただし１７年の記事）

上の記事ではSEOとパフォーマンスの改善がメリットに挙げられている。

しかしSEOについてはBotの改善でSSR必須ではないという話も上がっている。
GoogleがGoogleBotは食えると言ってるっぽい。
トラブルシューティング見てても、少なくとも基本は食ってくれるようなことも書いてある。

デメリット

デメリットにはSSR処理の負荷が高いことが挙げられている。
これもある程度テクニックで緩和できるらしい。

SSRを用意運用する複雑さも難易度高そうと思ったが、
Next.jsやNuxt.jsなどのFWを使えば複雑さはある程度無視できるとも考えている。

フレームワーク選定

ReactのFW候補にNext.jsとGatsbyが挙げられた。
Next.jsはNuxt.jsの原型なので特性はほとんど変わらないと勝手に思っている。

フレームワークの比較はこの記事が非常にわかりやすかった。
Gatsbyの記事だが他のフレームワークの特性も一緒に学習できた。
※CRAは素のReactと考えて良さげ。

Gatsbyの特性

静的サイトジェネレータ

Gatsbyは「静的サイトジェネレータ」と呼ばれる機構を持つ。
SSRはリクエスト時にHTMLを組み立てるが、Gatsbyは事前にビルドしてHTMLなどを生成する。
もちろん動的な挙動も可能らしい。

Gatsbyのデメリット

静的サイトジェネレータの特性上、
頻繁に内容を変更するプロダクトには向かないらしいが、動的レンダの仕組みもあるので問題ない気もする。

Nextに比べるとめんどくさいという話なんだろうか？🤔
Gatsbyのデメリットを知りたいところ。

Gatsby「難しい」のがデメリットらしい。

Wordpressと比較されることが多い？
フロントエンド（HTML、CSS、JS、SEO）の知識が要求される点が挙げられている。

結論

現在調べる限り、ReactでGatsbyを使うのが一番良さそうに感じた。

Gatsbyのデメリットであるフロントの知識については、チームメンバーを鑑みて問題ないと考えている。