Next.jsの段階的導入

2020年11月18日（水）
投稿者：Lee Robinson @ leerob

Next.jsは段階的な導入を念頭に設計されています。Next.jsを使用することで、既存のコードを継続して使用しながら、必要に応じてReactを追加できます（多くても少なくても構いません）。小さく始めて段階的にページを追加することで、完全な書き換えを避け、機能開発の妨げを防ぐことができます。

多くの企業は、コスト削減、開発者の生産性向上、顧客への最高のエクスペリエンス提供のために、技術スタックの近代化が必要です。コンポーネント駆動開発は、現代のコードベースのデプロイ速度と再利用性を大幅に改善しました。月間800万回以上のダウンロード数を誇るReactは、開発者にとってコンポーネント駆動開発の主要な選択肢です。

プロダクション向けのReactフレームワークであるNext.jsは、Reactの段階的導入を可能にします。

動機

モバイル化が進む世界において、Core Web Vitalsの改善と追跡は成功に不可欠です。顧客は世界中に分散しており、インターネット速度も様々です。ページの読み込みやアクションの完了を待つ時間が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内でリライトを使用して、一部のサブパスを既存のアプリにプロキシできます。

例えば、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統合によって提供されるDeployment URLの例。

まとめ

Next.jsは既存の技術スタックへの段階的導入を念頭に設計されました。Vercelプラットフォームは、GitHub、GitLab、Bitbucketとシームレスに統合し、すべてのコード変更にデプロイプレビューを提供することで、協調的な体験を実現します。

• Fast Refreshでローカルでの変更を即座にプレビューし、開発者の生産性を向上
• 変更をプッシュしてBranch Previewを作成し、ステークホルダーとの協力に最適化
• PRをマージしてVercelでプロダクションにデプロイ。複雑なDevOpsは不要

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