Next.jsで加速するWebアプリケーション開発 - Forkwell Library #31に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。
しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第31回目では、2023年7月22日発売の『基礎から学ぶ Next.js』著者の大島 祐輝氏をお招きし、お話を伺います。
「Next.js」を使ってWeb開発を行うための入門書である本書では、Next.jsの機能と、それらを活用したWebアプリケーション開発の方法を解説しています。また、React/Next.jsを利用するに当たっての前提知識からReact/Next.jsの基本はもちろん、Next.jsを使った実際のアプリケーション開発のハンズオンを行っています。 今回は著者の大島 祐輝氏に、Next.jsでの開発の方法とメリットの紹介に加え、プロトタイピングのフェーズに焦点を当てて、Next.jsを活用することでまず動くものを高速で作ることができる点についてお話しいただきます。

会の様子

書籍の概要

Next.jsの基礎的な話を紹介しつつ、Next.jsを活用することでWebアプリケーションにおけるプロトタイピングが加速していくことを語っているという話が本の概要として紹介されました。

Next.jsの特徴

Next.jsの特徴として、

• ファイルベースルーティング
• ルートハンドラ
• サーバサイドレンダリング

が挙げられました。以下、それぞれの内容に関して具体的に記載します。

ファイルベースルーティング

App Routerでファイルを基準としたページルーティングを実現しているという話がありました。
内容としては、以下が紹介されていきました。

• 非同期関数をreturnし、サーバーコンポーネントを記載するpage.tsx
• 配下のページに共通のレイアウトを定義するためのlayout.tsx
• Suspendによるローディング機能を記載するloading.tsx(PromiseをPendingする際に表示する内容)
• Promiseがrejextされた場合に表示する内容を記載するerror.tsx

ルートハンドラ

続いて、app/api配下のファイルがAPIのエンドポイントとして機能するようになるルートハンドラの紹介がありました。

ここで、エンドポイントのURLもファイルパスに対応するという話も紹介されました。

サーバサイドレンダリング

最後にサーバーサイドレンダリングの紹介がありました。

サーバーサイドレンダリング自体はNext.jsの特徴として以前から語られていますが、Next.js 13からはApp RouterではReactコンポーネントがデフォルトでサーバーコンポーネントとなるようになり、コンポーネント単位でサーバーサイドレンダリングが行われるようになるということでした。

サーバーコンポーネントは、バックエンドに直接アクセスして秘密情報を利用できるprosと、状態管理やイベントハンドラなどのAPIが利用できないconsに分かれるという話も出ていました。

また、サーバーコンポーネントではfetchのレスポンスをキャッシュでき、静的/動的レンダリングが切り替え可能であり、具体的な設定としてSSG/SSR/ISRがあるというお話が出ていました。

Next.jsのメリット

Next.jsのメリットとして以下が挙げられていました。

• オールインワンのボイラープレートであり、1コマンドで開発を開始できる
• 宣言的なルーティングができるため可読性が高い上に、Layoutで共通レイアウトを定義できる
• バックエンドデータ取得方法が多様であり、SSG/SSR/ISRの使い分けやクライアントコンポーネント/サーバーコンポーネントの使い分けができる

Next.jsで加速するプロトタイピング

Next.jsで開発が加速するという内容の具体化として、プロトタイピングの加速になぜNext.jsが寄与するのか？という話がありました。

プロトタイピングの加速に寄与する要素としては以下の点が挙げられていました。

• Webアプリケーションを実装するにあたってはフロントエンド/バックエンド双方で多数必要な要素があるが、Next.jsは基本領域(DBとインフラは除く)をすべてカバーできているため動かすまでが早い
• ユースケースに合わせて柔軟に実装できる
• インフラストラクチャ構築が早い
• APIリクエスト/レスポンスの型共有が容易

Q&A

講演の後はQ&Aがありました。以下、質問の内容と回答を常体で記載していきます。

use server/server actionについてどのようなユースケースで扱われるか聞いてみたい

安定してきたら触ってみたいと思っているが、HTMLのフォーム要素をサーバーコンポーネントに上手いこと組み込めないか？という試みである印象を受けた。

コンポーネント側のプレゼンテーション層とデータアクセス層の分離になにかデザインパターン・アーキテクチャを使っているか？

Recoil。ただし開発が停滞している印象があるのはネック。
あとはJotaiも似たようなライブラリとしてはある。

NetlifyなどVercel以外でデプロイする場合のTipsや注意点は？

あんまり経験していないので回答が難しい。

Reactのみで良い場合、Next.jsを導入する場合はどのように判断するのか？

Reactのみは基本難しいと思っている。
BFFは別で作ることが決まっている場合や、完全にSPAでいい場合はtoo muchな感覚はある。

App Router/Page Routerどちらをどういう理由で選ぶか？

Page Routerしかできない機能はないので、App Routerが基本になるとは思う。

一方でApp Routerだとデフォルトですべてがサーバーコンポーネントになる点は注意が必要。

バックエンドに直接リクエストできるのは、フロントエンドで秘密鍵を保持するためセキュリティ的に問題がでるのではないか？

コンポーネントの中でリクエストするのでサーバーからは結果だけが返ってきている。
Next.jsでは頭にpublicをつけたりしなければ基本的に秘匿は担保されるので問題ない。

Tailwindが利用できない場合どのようなCSSフレームワークを利用するのか？

Tailwind一本で運用しているので上手く答えられない。

App Routerを導入する上ではRSCに寄せるべきかの議論に関してどう思うか？

ユーザーとインタラクションがあるコンテキストだと、クライアントサイドコンポーネントにする必要が出てくるので、使えるところ/使えないところがはっきり分かれ、そんなに議論する必要がある場面は少ないのでは？と思う。

App Routerでコンポーネントの階層が深くなるとサーバーコンポーネントとクライアントコンポーネントの区別がつきにくくなると思うが何か工夫していることはあるのか？

サーバーコンポーネントとクライアントコンポーネントを色分けするようなユーティリティはある。

プロトタイプを作る場合データベースはどこがよいか？

ユースケースによるのではないかと思う。

会全体を通した感想

進化の速度が早い領域ということもあり、本を書いている間にNext.js 13の話が出たことで内容を書き直ししたという話からは執筆の大変さが伺えました。

また、App Router周りの関心度の高さがQ&Aから伺えたのは今回のイベントで参加したことで得た大きな学びの一つとなりました。