Zenn
Open7

2020年末からWebフロントエンドをキャッチアップした記録

rocknamerockname

1. Webアプリパターンの歴史 - SST、AJAX、CSR、SSR、SSG、そしてISR

上から順に現在に向かう流れ

SST (Server Side Templating)

RailsのERBのように、サーバサイドで取得したデータをテンプレートに流し込んでHTMLを生成し、それをブラウザに返す形式

AJAX (Asynchronous JavaScript + XML)

XMLHttpRequestでGETやPOSTメソッドを利用してAPIからデータを受け取り、JQueryなどでHTMLを動的に更新する
この時はまだJavaScriptはHTMLのおまけ的存在

CSR (Client Side Rendering)

SPA (Single Page Application) の始まり
最初にほぼ空のHTMLを読みこみ、React、Vue.js、AngularなどのJavaScriptライブラリでDOMを生成・操作する
この辺でJavaScript中心になってきて、よりリッチなWebページが要求されるようになってきた

SSR (Server Side Rendering)

サーバーがリクエストを受けた時点でJavaScriptを実行してHTMLを生成し、それをブラウザに返す
Next.js や Nuxt.jsなどのフレームワーク
当時はSEOの観点で良いとされていたが、今はGoogleのクローラーがJavaScriptを実行できるようになったので、メリットは相当薄い(Twitter等のJS実行できないクローラーのために動的なOGPを生成する必要がある場合はSSR必要というくらい)

SSG (Static Site Generation)

ビルド時にあらかじめ静的なファイルを生成する
JAMStack で利用される
ただ、すべての有効なURLに対し、個々にHTMLファイルを生成しなければならないので、pathが動的に決まる場合には難題であり実行不可能になる

ISR (Incremental Static Regeneration)

ビルド後に静的生成されたページを追加したり、更新したりできる
Next.js 9.5 より正式な機能として提供
ビルド時にpathが生成されなかったページは、ユーザーの要求のタイミングでページを生成し、次のアクセス以降は生成したページを返す、取得したデータに変更があった場合はページを再生成する

感想

  • ISRってSSGのデメリットを克服していて最高！って思ってたけど、認証必要なページはどうにも使えそうにない気がする
  • ブログみたいなほぼ静的ページにしか使えないのでは？
  • それも例えばいいね機能があるブログなら、そのユーザーが既にいいねを押してるかの情報を表示する時点で結局使えなさそう…
rocknamerockname

2. Frontend Study #1: 基調講演 - Frontend 領域を再定義する

  • 過去から現在, 未来まで、フロントエンドを俯瞰して述べられていてわかりやすかった
  • 現状は TypeScript + Next.js(Nuxt.js) がWebのベストプラクティスとのこと
  • この方は Fullstack Node.js or Jamstack+CMS に熱い期待を込めている
  • WebAssembly にも期待しているが、まだまだ枯れてない様子
rocknamerockname

3. React Server Components はウェブ開発を変えるゲームチェンジングな技術である

  • 昨年末突如として現れたReact Server Componentsについて触れた記事
  • React Server Components ではサーバー側でレンダリングするサーバーコンポーネントとクライアント側でレンダリングするクライアントコンポーネントをファイルの命名のみで切り替えることができる技術
  • APIリクエストやDBアクセスの処理を持つコンポーネントをサーバーコンポーネントとして定義し、レンダリング済みの物をクライアントコンポーネントが組み込んで描画するらしい
rocknamerockname

4. React Server Componentsに感じたフロントエンドの消失

  • React Server ComponentsやフルスタックJSに対して疑問を投げかけた記事
  • 上記技術はフロントエンドとバックエンドの境界を曖昧にするもの
  • そもそもフロントエンドとバックエンドが分かれている必要があるのかという話に発展
  • 事業規模やチーム編成にもよるが、性能的に問題ないのであれば密結合な方が生産性は高い、そうなるとフロントエンドというカテゴリが曖昧になるなぁという話
  • 自分がiOSをメインで書くエンジニアだからかわからないが、やはり「フロントエンド(Web, iOS, Android)」と「APIサーバー」の境界はあって欲しいなと感じる
    • 単純に保守性が高まるのと、各チームメンバーがキャッチアップする技術分野を狭める形を取れた方が望ましいなと
  • なので後半のこの部分はかなり同意できる

「React Server ComponentsでAPI統合はもちろんDB直アクセスもできる」とか「Blitz.jsで永続化層を持たせれる」と言われてもピンとこないどころか「筋が悪いのでは？」とすら感じてしまってた

  • https://zenn.dev/erukiti/articles/universal-wars にてこの記事に対するアンサーが書かれていた
  • React Server Componentsの立ち位置としてはただコンポーネント単位でSSRできるよというだけで、そこでWeb APIリクエストするもDBアクセスするも使い手側の自由である、という旨の記述があった
  • フロントエンドとバックエンドの関係についての言及もあった
  • React 専門家とRails 専門家を例にお話しされていて非常にわかりやすかった、採用する技術が単一である方がすべてのメンバーが触ることができて明らかに良いよね、という話
  • 個人的には「専門家」という言葉で誇張されてしまっている部分を「軸足を置く人間」と置き換えて、その人がそれぞれの分野をリードする形でお互いがどちらの領域のコードを書く形が組織の形としては好きだなぁと感じ、改めてユニバーサルフレームワークに固執することもないなぁと思った
rocknamerockname

5. Micro Frontends Architecture Patterns

  • 密結合の議論の話があった後にではあるが、Micro Frontendsの記事を読んだ
  • かなり体系的にまとまっていて、これが無料公開されているのに驚愕...
  • Client Side Composition, Edge Side Composition, Server Side Compositionなど全く知らなかったので、チームの規模が大きい開発組織は選択肢として握っておくと良さそう
rocknamerockname

とりあえずまとめ

レンダリングについて

  • 認証情報を必要としない、マウント前に表示情報を取得するようなほぼ静的なページ → SSG/ISR
    • レンダリング済みページをCDNに乗せることができるこの形が一番理想ではある
  • それ以外 → CSR
    • SSRは特別な理由がない限り採用することはなさそう
    • React Server Component が普及すれば通信部分はサーバーコンポーネントでSSRできると良さそう

フロントエンドとバックエンドについて

  • ユニバーサルフレームワークで密結合に作るのも、APIサーバーと切り分けて開発するのもどちらにもメリット/デメリットは存在する
  • React Server ComponentやフルスタックJSの台頭で、「JSでフルスタックに開発するのが主流！」と判断するのは早計で、しっかりチームの規模や事業のフェーズと相談して選択していくのが良さそう