RemixからNext.jsに移行した話Migrating from Remix to Next.js

Remix / React Router と Next.js の比較

Comparison of Remix/React Router and Next.js

Remixと比較したNext.jsのよいところ

Advantages of Next.js Compared to Remix

1. React 19がフルに活用できる

   Full Utilization of React 19

   Remix / React Router v7 だと、route modulesの loader / action でデータを扱うため、コンポーネントとデータ部分が分離しがちでした。
   Next.js（App Router）ではRSC (React Server Components) や Server Actions ､useActionState等を活用することで、コンポーネントとデータの距離が縮まり、開発生産性が向上しました。また､コロケーションに基づいたディレクトリ構成がRemixより行いやすくなった点も開発生産性の向上に繋がりました｡

   With Remix/React Router v7, data handling within route modules' loaders/actions often resulted in a separation between components and data. Next.js (App Router), using RSC (React Server Components), Server Actions, useActionState, etc., minimizes this distance, improving development productivity. The directory structure based on colocation is also easier to implement than in Remix, further boosting productivity.

2. 豊富なエコシステム

   Rich Ecosystem

   Next.jsの場合､Sentry、Supabase、Stripe など多くのサービスの公式例があり、周辺ライブラリも充実しています。next/font や next/image も素晴らしく、これによってLight HouseのPerformanceが100点になり､Best Practicesも100点になりました｡

   Next.js boasts official examples for many services like Sentry, Supabase, and Stripe, and abundant supporting libraries. next/font and next/image are excellent, resulting in a perfect Lighthouse Performance and Best Practices score of 100.

   

   移行前は以下の点数だったので､エコシステムの力を大いに感じています｡(Accessibility頑張ります｡)

   Before the migration, the scores were lower, highlighting the significant impact of the ecosystem. (We'll work on Accessibility!)

   

3. AIフレンドリー

   AI-Friendly

   ClaudeやGPTに､Remixで書いてと指示を出してもNext.jsのコードを吐いてくることがよくありました｡ユーザが多い分､Next.jsの場合最初から使えるコードを出してくれる割合が増えたと感じます｡これもAI時代の新たなエコシステムと呼べるかもしれません｡

   When asking Claude or GPT to write code in Remix, it often generated Next.js code. The larger user base seems to increase the likelihood of Next.js producing usable code from the outset. This could be considered a new ecosystem for the AI era.

Remixと比較したNext.jsのよくないところ

Disadvantages of Next.js Compared to Remix

1. ビルドが遅い

   Slow Build Times

   Remix は HMR が速く、ローカル開発が非常に快適でした｡Next.js はファイルによってはビルドに数秒かかり、時にはリロード必須になるなど、開発体験としてはストレスがあります。

   Remix's HMR is fast, providing a very comfortable local development experience. Next.js, however, can take several seconds to build certain files, sometimes requiring a manual reload, resulting in a frustrating development experience.

2. メンタルモデルの複雑さ

   Complex Mental Model

   Remixのメンタルモデルは､loader→component→actionというシンプルでわかりやすい流れでした｡

   Remix's mental model is simple and clear: loader → component → action.

   Next.jsの場合､RSC/Server Actions/revalidatePath/revalidateTag/next/dynamic/Request Memoizationなど様々な概念が登場します｡最適化されたことでLighthouseのスコアは上がりましたが、体感ではRemixの時と速度に差はありません。ユーザとしては体感速ければどうでもいいので､勝手に速くなるようにしてほしいという感想です｡

   Next.js introduces various concepts: RSC/Server Actions/revalidatePath/revalidateTag/next/dynamic/Request Memoization. While optimization improved Lighthouse scores, the perceived speed wasn't noticeably different from Remix. As a user, I just want it to be fast; I don't care how it's achieved.

3. 黒魔術

   Dark Magic

   Remixの吐くhtmlは非常にシンプルでした。書いたものがそのまま出力されているという感じで、把握しやすかったです。

   Remix generates very clean HTML; what you write is what you get, making it easy to understand.

   Next.js はフレームワーク独自のロジックでclassNameやcanvasタグが差し込まれていたり、デバッグが複雑です。また､Edge Runtimeと絡んで､ローカルでは動くのに本番だと動かない問題にも遭遇しがちです｡

   Next.js inserts framework-specific logic (e.g., className, canvas tags), complicating debugging. Issues where code runs locally but fails in production, often involving Edge Runtime, are common.

移行ステップ

Migration Steps

1. ライブラリ移行とDBスキーマ変更

1. Library Migration and DB Schema Changes

最初にブランチを切ってcreate next し､ライブラリの移行から始めました｡具体的には以下のライブラリを移行する必要がありました｡

I started by creating a new branch with `create next` and began migrating libraries. This included the following:

• remix-auth → auth.js

  remix-auth → auth.js

• react-i18next → next-intl

  react-i18next → next-intl

remix-auth → auth.jsの変更には､DBスキーマの対応とORMとして使っているPrismaのEdge Runtime対応が必要で､移行全体の中でもここが一番大変でした｡

The change to remix-auth → auth.js required adjustments to the DB schema and Prisma (our ORM) to support Edge Runtime. This was the most challenging part of the entire migration.

DBスキーマはauth.js側に合わせたスキーマを用意し、既存データをマイグレーションし､カスタマイズを減らすことでアップデート時のリスクを抑えました。

For the DB schema, I prepared a schema matching auth.js, migrated existing data, and minimized customizations to reduce upgrade risks.

Edge Runtimeは､Prisma Accelerate はまだ事例が少なく、ローカルと本番の差異が大きそうで懸念があり､Drizzle への移行は自由度が高い一方で工数が大きいので､結果、Neon + Prisma を選択して最小限の工数に留めました。

For Edge Runtime, Prisma Accelerate lacked sufficient examples, and the potential for significant differences between local and production environments was concerning. While migrating to Drizzle offered high flexibility, it would have been more time-consuming. As a result, I opted for Neon + Prisma, keeping the effort to a minimum.

2. Remix 向けコードを Next.js に書き換え

2. Rewriting Remix Code for Next.js

次に、既存の Remix のルーティングや loader / action 部分を、Next.js App Router での RSC / Server Actions に置き換えました。
ここではAIが非常に役に立ちました｡と言ってもuseActionStateやServer ActionはまだAIには書けないので自力で頑張る必要があります｡

Next, I replaced existing Remix routing and loader/action components with Next.js App Router RSC/Server Actions. AI was extremely helpful here. However, useActionState and Server Actions still require manual coding.

RSC / Server Actions のTips

RSC/Server Actions Tips

1. Server Actions に共通ロジックを持たせない工夫

   Avoiding Shared Logic in Server Actions

   すべての Server Actions が外部公開されるため、認証コードをいちいち書く必要があります。できるだけ認証ロジックをまとめた関数や、Middleware で対応できないか検討しましょう。

   Since all Server Actions are publicly accessible, authentication code is needed for each. Consider using functions or middleware to consolidate authentication logic where possible.

2. RSC コンポーネントのテスト

   Testing RSC Components

   RSC は 現状テスト手法が確立されていないので､ビジネスロジックや認証ロジックを分け、Unit テスト可能にするのがおすすめです。

   Testing methodologies for RSC are still under development. Separating business and authentication logic makes unit testing easier.

3. useActionState の型付け

   useActionState Typing

   useActionStateの返り値に型情報を付与する仕組みはまだ確立されていません。自前で定義するのが現状ベターです。個人的には以下のようにしています｡(about_hiroppyさんのtweetを参考にしています｡)

   A mechanism for adding type information to the return value of useActionState isn't fully established. Defining types manually is currently the better approach. I use the following method (inspired by @about_hiroppy's tweet).

   export type ActionResponse<T = void, U = Record<string, unknown>> = {
   	success: boolean;
   	message?: string;
   	data?: T;
   	zodErrors?: typeToFlattenedError<U>["fieldErrors"];
   };

4. form の型検証

   Form Validation

   Server Action 内でバリデーションするといいです。個人的にはzodで以下のようにしています｡

   It's best to perform validation within Server Actions. I personally use zod as follows:

   const editPageContentSchema = z.object({
   	slug: z.string().min(1),
   	title: z.string().min(1).max(100),
   	pageContent: z.string().min(1),
   });
   	
   const parsedFormData = editPageContentSchema.safeParse({
   		slug: formData.get("slug"),
   		title: formData.
   
   

結論：規模やチーム体制で選ぶ

Conclusion: Choose Based on Scale and Team Structure

• 小〜中規模のアプリ

  Small to Medium-Sized Apps

  • そこまで最新の React 機能を活用しなくても良ければ、Remix / React Router はシンプルで高速な開発体験を得やすい。メンタルモデルも明快。

    If you don't need to utilize the latest React features extensively, Remix/React Router offers a simple and fast development experience. The mental model is also straightforward.

  • toBやSPAなら個人的にはRemix / React Router｡

    For B2B or SPAs, I personally recommend Remix/React Router.

• 中〜大規模 or エコシステムを活かしたい場合

  Medium to Large-Scale or Those Wishing to Leverage the Ecosystem

  • Next.jsを選べばサービス・ライブラリとの連携がしやすく、将来的な React のアップデートにも先行して対応できる。

    Next.js facilitates integration with services and libraries and provides early access to future React updates.

  • toCやSSRをしたいならNext.js｡

    For B2C or SSR, choose Next.js.

個人的には「リリースして伸びてきたら Next.js に移行」というアプローチも十分アリだと思います。Remix/React Routerならcloudflareを使えばコストもかなり抑えられます｡ただし、移行時はやはり工数も掛かるので、将来的な拡張を見据えている場合は最初から Next.js を使う選択肢も強いです。

I believe that migrating to Next.js after initial release and growth is a perfectly viable approach. Remix/React Router with Cloudflare keeps costs down. However, migrations are time-consuming, so choosing Next.js from the start is a strong option if you anticipate future expansion.

おわりに

Closing Remarks

フレームワーク､DB､インフラの移行と大掛かりな変更だったのですが､重要な部分にテストコードを書いていたことや､DB周りのコードをCQRSで分離していたことで、認証周り以外は比較的スムーズでした。改めて、コードの品質やアーキテクチャに投資することが大事だと実感しています。

The migration of the framework, database, and infrastructure was extensive. However, having test code for critical parts and separating DB code using CQRS resulted in a relatively smooth process, except for authentication. I've reaffirmed the importance of investing in code quality and architecture.

このサイト「Evame」は、書いた記事やコメントをAIが自動翻訳してくれる多言語コミュニティです。僕もこの移行記を日本語で書き、英語圏にシェアできるようになりました。

Evame is a multilingual community where AI automatically translates articles and comments. This migration allowed me to write this migration report in Japanese and share it with an English-speaking audience.

もし興味があれば、ぜひ好きな言語で記事を書いて、世界中に発信してみてください！

If you're interested, please write an article in your preferred language and share it with the world!

以上が、Remix / React Router v7 から Next.js へ移行した感想と比較、そして移行手順です。何か参考になる部分があれば嬉しいです！

These are my thoughts, comparisons, and migration steps from Remix/React Router v7 to Next.js. I hope this is helpful!