Next.js の段階的な導入

Next.jsは、段階的な導入のために設計されています。Next.js を使用すると、既存のコードを引き続き使用し、必要なだけ (または少しだけ) React を追加できます。小さな規模から始めて、徐々にページを追加していくことで、完全な書き直しを避けて、機能開発の脱線を防ぐことができます。

多くの企業は、コストを削減し、開発者の生産性を向上させ、顧客に最高の体験を提供するために、テクノロジースタックを最新化する必要があります。コンポーネント駆動開発は、最新のコードベースのデプロイ速度と再利用性を大幅に向上させました。

そして、月間 800 万件以上のダウンロード数を誇る React は、開発者にとって主要なコンポーネント駆動型の選択肢となっています。Next.js は、本番環境向けの React フレームワークであり、React を段階的に導入できるようにします。

動機

モバイル化が進む世界では、コアウェブバイタルを改善し、追跡することが成功のために不可欠です。顧客は、インターネット速度が異なる世界中に分散している可能性があります。ページの読み込みやアクションの完了を待つために費やされる追加の 1 秒 (またはミリ秒) は、販売、インプレッション、コンバージョンの違いになる可能性があります。

テクノロジースタックを最新化する場合、次のような課題に直面している可能性があります。

アプリケーションには、理解するのが難しく、完全に書き直すのに何年も (そして数百万ドルも) かかるであろう、長年のレガシーコードがあります。
アプリケーションのサイズと複雑さが増すにつれて、ページ読み込み時間がますます長くなっています。単純なマーケティングページは、最も複雑なページと同じくらい遅いです。
開発チームを拡大しようとしていますが、既存のコードベースに開発者を追加する際に問題が発生しています。
開発者の生産性を低下させ、新しい変更を安全かつ確実に展開することを困難にする、古い CI/CD および DevOps プロセスがあります。
アプリケーションはモバイルデバイスに対応しておらず、アプリケーションの他の部分を壊さずにグローバルページスタイルを更新することは不可能です。

何かする必要があることはわかっていますが、どこから始めればよいかを理解するのは大変なことです。Next.js を段階的に導入することで、上記の問題を解決し、アプリケーションを変革することができます。既存のテクノロジースタックに Next.js を導入するためのいくつかの異なる戦略について説明しましょう。

戦略

サブパス

最初の戦略は、特定のサブパス下のすべてが Next.js アプリを指すように、サーバーまたはプロキシを構成することです。たとえば、既存の Web サイトが example.com にあり、example.com/store が Next.js e コマースストアを提供するようにプロキシを構成する場合があります。

basePath を使用すると、Next.js アプリケーションのアセットとリンクが新しいサブパス /store で自動的に動作するように構成できます。Next.js の各ページは独自のスタンドアロンルートであるため、pages/products.js のようなページはアプリケーションの example.com/store/products にルーティングされます。

next.config.js

module.exports = {
  basePath: '/store',
};

basePath の詳細については、ドキュメントをご覧ください。

(注: この機能は Next.js 9.5 以降で導入されました。古いバージョンの Next.js を使用している場合は、試す前にアップグレードしてください。)

リライト

2 番目の戦略は、ドメインのルート URL を指す新しい Next.js アプリを作成することです。次に、next.config.js 内で rewrites を使用して、既存のアプリにプロキシされるようにいくつかのサブパスを設定できます。

たとえば、次の next.config.js を使用して example.com から提供される Next.js アプリを作成したとします。これで、この Next.js アプリに追加したページ (pages/about.js を追加した場合の /about など) のリクエストは Next.js によって処理され、その他のルート (/dashboard など) のリクエストは proxy.example.com にプロキシされます。

next.config.js

module.exports = {
  async rewrites() {
    return [
      // we need to define a no-op rewrite to trigger checking
      // all pages/static files before we attempt proxying
      {
        source: '/:path*',
        destination: '/:path*',
      },
      {
        source: '/:path*',
        destination: `https://proxy.example.com/:path*`,
      },
    ];
  },
};

リライトの詳細については、ドキュメントをご覧ください。

モノレポとサブドメインを使用したマイクロフロントエンド

Next.js と Vercelを使用すると、マイクロフロントエンドを簡単に導入し、モノレポとしてデプロイすることが容易になります。これにより、サブドメインを使用して、新しいアプリケーションを段階的に導入できます。マイクロフロントエンドのいくつかの利点

より小さく、よりまとまりがあり、保守しやすいコードベース。
分離された自律チームによる、よりスケーラブルな組織。
フロントエンドの一部をより段階的にアップグレード、更新、または書き直す機能。

Vercel にデプロイされたモノレポのアーキテクチャ。

モノレポをセットアップしたら、通常どおり Git リポジトリに変更をプッシュすると、接続した Vercel プロジェクトにコミットがデプロイされることがわかります。古い CI/CD プロセスに別れを告げましょう。

Git 統合によって提供されるデプロイメント URL の例。

結論

Next.js は、既存の技術スタックに段階的に導入できるように設計されています。Vercel プラットフォームは、GitHub、GitLab、Bitbucket とシームレスに統合することで、すべてのコード変更に対してデプロイプレビューを提供し、共同作業を可能にします。

Fast Refresh を使用して、ローカルで変更を即座にプレビューできるため、開発者の生産性が向上します。
ブランチプレビューを作成するために変更をプッシュし、関係者とのコラボレーションに最適化されます。
PRをマージすることで、複雑な DevOps なしに、Vercel にプロダクションデプロイします。

詳細については、サブパスとリライトについて読むか、マイクロフロントエンドの例をデプロイするを参照してください。