Next.js Conf 2024 全部聞いてみた
🔼

Next.js Conf 2024 全部聞いてみた

2024/10/28に公開

こんにちは、絶賛スウェーデンに留学中のきたぴーと申します!今回は Next.js Conf 2024 をリアタイ視聴して内容を大まかにまとめてみたので記事にして共有してみようと思います!

聞いてみようと思った背景

個人開発でもインターンでもハッカソンでも、自分はいつでも Next.js にお世話になっているので最新機能や、Next.js 開発チームの思想を直接聞くことで視座を少しでも近づけたいと思ったのがきっかけです。タイムテーブルを見ると、「サーバコンポーネントで向上する UX」のような Next.js の機能について扱うものから、Perplexity や PayPal での導入事例のような応用例まで取り上げられていた、かつ Vercel が公式でピックアップしたものなので情報の密度も濃いものだろうと、非常に興味が湧きました。あとは時間の都合も良く、日本だったら深夜の 1:30 スタートなところをスウェーデンでは夕方 18:30 から見ることができたので聞いてみようと思った次第です。

なので、技術的な解説は以下の Next.js 公式ブログにお任せすることにします!Turbopack の導入や use cache によるキャッシュ戦略のシンプル化、など技術的な詳細はこちらの記事を参照いただければと思います!
https://nextjs.org/blog/next-15
https://nextjs.org/docs/canary/app/api-reference/directives/use-cache

この記事について

この記事のまとめ方については時系列順ではなく、技術的な解説をしているものと実プロダクションへの応用事例を解説しているものという形でまとめていこうと思います!

また、英語の聞き間違いや的外れな要約をしている可能性はあると思うので、指摘があればぜひ教えていただきたいです!よろしくお願いします!!

オープニング

VJ から始まり、基調講演、AMA (Ask me anything) セッションという流れでした。

基調講演は、Vercel の CEO である Guillermo Rauch による Next.js で飛行機のチケットを予約する Web アプリケーションのライブコーディングから始まりました。そのほか、Turbopack によるコンパイル時間の短縮 (対応状況が見れるページ) や、use cache による明示的なキャッシュの取り扱いについて語っていました。

各種 PaaS 向けのテンプレートを公開したらしく、Render、Fly.io や Cloud Run など執筆時点で 10 個ほどテンプレートがあり、リポジトリ立ち上げの時にめちゃ助かりそうだなと思いました。以下の Next.js Organization のページから閲覧できます。
https://github.com/nextjs

個人的に印象に残っているのが

Make it Work → Make it Right → Make it Fast

と書かれた、Next.js で実現できる開発体験を説明したスライドでした。まずは動くものを作れて、その後に信頼性を検証できて、さらにパフォーマンス最適化まで行えるという表現です。プロダクトの仮説を立ててユーザに提供してフィードバックを得るというアジャイルの工程を早く回せる開発体験を実現しようとしているチームの思想が垣間見えた気がしました。昨今のプロダクト開発のニーズにピッタリ合うように設計されているんだな、と実感しました。

Next.js の機能について

Inmeta: サーバコンポーネントで向上する UX

サーバコンポーネントを利用して、重いデータフェッチングがあるページでも UX を損なわずに Lighthouse Score が 60 なページを 100 にする実装方法をライブコーディングしつつ解説していました。

サーバコンポーネントを使用することで、バックエンドリソースへ簡単にアクセスできるほか、クライアントのバンドルサイズが小さくなるというメリットがあるそうです。

このセッションは、タスク管理アプリケーションのデータフェッチや検索機能についてサーバコンポーネントを使いながらローディングのロジックを記述していく流れなんですが、実装の手順とそれによって改善する UX を同時に解説しているので本編をぜひ見てみてほしいと思います!

デモに使用していたコードは以下のリンクから覗けます!
https://github.com/aurorascharff/next15-filterlist

Peloton: クライアントレンダリングから静的サイトへの移行

既存のシステムを Next.js に置換するにあたって、2 つの方法を検証したといいます。

  • Incremental な移行: 既存のアプリケーションを残しつつページや機能単位徐々に置き換えていく
    • メリット: システム停止をしなくていいためユーザ影響が少なく、チームとしても新たな Next.js という技術への移行期間を設けられる
    • デメリット: 期間が長期化し、マイグレーション中のコードは複雑になる
  • All-at-once な移行: 既存のアプリケーションを一度に移行する
    • メリット: 短期間で移行を完了でき、技術スタックが統一され運用保守がシンプルになり、さらに Next.js の最適化機能の恩恵をフルに享受できる
    • デメリット: システム全体を停止しなければならなく、ユーザ影響が大きいかつ、短期間で工数も大幅に取られる

以上のことから、大規模なシステムやチームにスキルが不足している場合には Incremental な移行、小規模でリスクを許容できチームのスキルが高い場合には All-at-once な移行という選択肢になるだろう、と話していました。

その中で Peloton は、最初は Incremental な移行からスタートし、SEO や Prerendering など Next.js の恩恵をすぐに受ける必要のない他の部分では All-at-once の移行をするという決断をしたそうです。

Vercel: Partial Prerendering

動的なレンダリングと、静的なレンダリングの 2 種類があります。それぞれ、データフェッチをする代わりに低速なレンダリングと、データフェッチをしない代わりに高速なレンダリングのことです。それらの長所を組み合わせてレンダリングしようという概念が PPR: Partial Prerendering という概念です。

静的な HTML シェルをクライアントに送っている間に、バックエンドではデータフェッチングを行い、それが終わり次第、クライアントに送った HTML シェルのプレースホルダを置換するというものです。

まだ実験的な機能ですが、LCP に対するパフォーマンスや UX を向上できる上、SEO 対策にもなり開発体験もいいと激推ししていました。

https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering

プロダクションで利用される Next.js

New York Public Library: サイトリニューアル

大量のデータに対して無料かつ、あらゆる人に対してオープンに公開するという目標のもと、WCAG のサポートや SEO 対策といった技術的課題に立ち向かう必要がありました。元々は、Rails を採用していましたが、以下の要素から Next.js にリプレイスすることにしたそうです。

  • セットアップからデプロイまでの簡便さ
  • (サーバでもクライアントでも) ハイブリッドなレンダリングができる
  • ファイルベースルーティングや充実したドキュメントなど開発体験の良さ

デザインシステムとして、Chakra UI をベースに改良した Reservoir Design System をオープンソースプロジェクトとして開発したり、アクセシビリティのコンサルタントと開発を進めるなど、ユーザ体験にかなり力を入れて開発しているようでした。

https://www.nypl.org/
https://github.com/NYPL/nypl-design-system

Perplexity: Generative UI

LLM を使って UI を改善することを Generative UI と表現し、それは単純なテキストに対するインタラクションから、Webページ全体の生成まで広範なものを指していました。

Generative UI を作るために以下の実装を行っているそうです。

  • 構造化データ: LLM には、事前に定義されたスキーマ (JSON など) をもとに生成させる
    • コンポーネントごとのスキーマは zod で定義する
    • LLM の非決定論的な性質を取り除き、安全性と信頼性を担保する
  • ストリーミング: LLM からの大きな応答を、チャンクに分割してクライアントへ徐々に配信する
    • パフォーマンスや UX が向上する
紹介されていた構造化データ + ストリーミングのコード
Timeline.tsx
const schema = z.object({
  timeline: z.array(TimelineItemSchema),
});

const Timeline = () => {
  const result = client.getTimeline();

  return (
    {/* StreamableSchema コンポーネントは、npm にヘルパーが
      * いっぱい転がっているので簡単に作れると紹介されていました。
      * Vercel の AI SDK とか使えば簡単に実装できそうですね
      * https://sdk.vercel.ai/docs/ai-sdk-rsc/streaming-react-components
      */}
    <StreamableSchema schema={schema} data={result}>
      {(item, metadata) => <TimelineItem {...item} {...metadata} />}
    </StreamableSchema>
  );
}
TimelineItem.tsx
const TimelineItemSchema = z.object({
  title: z.string(),
  date: z.string(),
});

type TimelineItemProps = z.infer<typeof TimelineItemSchema>;

type StreamingMetadata = {
  // レンダリング用のメタデータ、スキーマが完全か不完全かを示す
  isCompleted: boolean;
}

type Props = TimelineItemProps & StreamingMetadata;

const TimelineItem = (props: Props) =>
  props.isCompleted ? (
    <li>
      <h3>{props.title}</h3>
      <time>{props.date}</time>
    </li>
  ) : (
    <Loading />
  );

動作イメージ
動作イメージ

Generative UI のストリーミングという概念は、Perplexity の検索過程を示す UI に反映されているなと思いました。

Perplexity の Pro Search
Perplexity の Pro Search

PayPal: 新時代のプロダクト開発速度

PayPal のチェックアウトチームが、Next.js を使用した開発効率の高速化について行なっている施策を解説していました。

技術的には、tRPC でバックエンドの開発工数を削減し Storybook でコンポーネントの開発、テスト、ドキュメンテーションを一元管理していました。

また、チームの開発文化を変えていこうという戦略もとっていて、アクセシビリティチャンピオンプログラムと言う教育プログラムが印象に残っています。アクセシビリティへの深い理解と共感を持つためのプログラムで、アクセシビリティ監査やキーボードテストのスキル習得はもちろんのこと、ユーザの生活の実態について理解を深めるなど実践的な共感トレーニングも行っているとのことでした。すでに 90 人以上、トレーニングを修了していて、開発初期からアクセシビリティを考慮した設計ができていたとのことでした。

他にも feature フラグを使用して複数機能を並行開発できるようにしたり、コンポーネントが UX を満たしていているかの検証を Storybook の Play Function を利用して行なっているそうです。

Sanity: アプリケーションを "Live" に保つ

Web ページにおけるコンテンツの更新は、そのシステムが複雑なため即座にページに反映されないことが多いです。そのような昨今の Web システムに対して、そもそもページ上のコンテンツはオリジナルのものが変更された瞬間に反映されるべきではないのか?と言う問題提起から始まりました。

これを "Live by default" と呼び、更新ボタンやポーリング、キャッシュの混乱が発生せず、コンテンツの作者や編集者はエンドユーザが常に最新のコンテンツを見ていると考えれば良いと言う状況を作り出すことができるそうです。

静的なコンテンツの配信に特化している従来の CDN に対して、Sanity の Live Content API は動的なコンテンツや頻繁に更新されるコンテンツの配信に最適化された機能を提供しているとのことでした。

https://www.sanity.io/docs/live-content-api

聞いてみて

英語のカンファレンス、そもそも英語不慣れなこともあり内容についていくことが難しかったです。リアタイで内容は聞きながらざっくり Notion にまとめて、その後 Whisper で Speech to Text しつつ Gemini など使いつつ内容を要約したり、そしてそれが正しい内容かを Deepl を使用しつつ実際にアーカイブを見返したり・・・、こうして記事になるまでに2日くらいかかってびっくりしました笑

自分が Next.js、特にサーバコンポーネントをまだぜんぜん使いこなせてないと思ったのと同時に、リプレイスの流れなど、やはりソフトウェア開発において悩むところは世界中同じなんだなと実感しました。また「RSC で向上できる UX」セッションで紹介されていた useTransition や <Suspence /> による Promise オブジェクトをクライアントコンポーネントに渡せる機能など必要な UI 表現をサーバコンポーネントでシンプルに記述できるのはこれからの Next.js での Web 開発がより簡略化され、その結果、開発者のユーザと向き合える、プロダクトと向き合える時間がより増えていくんだろうなと思いました。

この記事にはまとめていませんが、最後にあった対談では Web アプリケーションがネイティブアプリと同じリッチなアニメーションやパフォーマンスを提供するためのインタフェースを提供するべきという言及もあったため、今後はアニメーション系の機能が拡充されたり、Image コンポーネントのような wasm で実装された最適化機能が新しく増えていくのかもしれません。

アーカイブの閲覧方法

今からでも参加登録をすればアーカイブは見ることができるので、ぜひスライドだけでも覗いてみてください!!
https://nextjs.org/conf

最後に

フレームワークの開発者や世界的に利用されているプロダクトの開発者が Next.js をどのように活用しているのかを聞くことができて、日本のカンファレンスとはまた違った刺激をもらえました!開発本国のカンファレンスを聞くのはいいぞ!!

と言うわけで、最後までお付き合いいただきありがとうございました🥳

Discussion