Backブログに戻る

Next.js の段階的な導入

Next.js を開発ワークフローに段階的に導入するためのさまざまな戦略について学びましょう。

Next.js は段階的な導入を想定して設計されています。Next.js では、既存のコードをそのまま使いながら、必要な分だけ React を追加できます。小規模から始めて徐々にページを追加していくことで、完全な書き換えを避けつつ機能開発を進めることが可能です。

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

そして月間 800万ダウンロード を超える React は、開発者にとって主要なコンポーネント駆動の選択肢です。プロダクション向け React フレームワークである Next.js は、React を段階的に導入することを可能にします。

動機

モバイル中心の世界において、Core Web Vitals の改善と追跡は成功に不可欠です。顧客は世界中に分散しており、インターネット速度も様々です。ページの読み込みやアクションの完了にかかる時間が1秒(または1ミリ秒)増えるごとに、売上、インプレッション、コンバージョンに影響が出る可能性があります。

技術スタックを近代化する際、次のような課題に直面するかもしれません:

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

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

戦略

サブパス

最初の戦略は、サーバーまたはプロキシを設定して、特定のサブパス配下のすべてを Next.js アプリに向ける方法です。例えば、既存のウェブサイトが 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 を使用して、一部のサブパスを既存のアプリにプロキシできます。

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

next.config.js
module.exports = {
  async rewrites() {
    return [
      // プロキシを試みる前にすべてのページ/静的ファイルを
      // チェックするために、no-op リライトを定義する必要があります
      {
        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 をマージして Vercel に本番環境へデプロイ。複雑な DevOps は不要

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