Alex Melia

核心的な理由

Next.js はステートレス、分散、エッジファーストのインフラのために最適化されている。

この前提を受け入れると、多くのことが避けられなくなる： • ローカルステート → 悪い • 長寿命プロセス → 悪い • メモリ内の何もかも → 悪い • ステートフルサーバー → 悪い • 「アプリの隣に Postgres を実行するだけ」 → 非推奨

では、そのものはどこに行くのか？

➡️ サードパーティサービス。

なぜこのバイアスが存在するのか

Vercelのプラットフォーム制約

Next.js は Vercel によって構築され、Vercel のプラットフォームは： • サーバーレス • 水平スケーリング • 一時的 • エッジ分散

つまり： • 保証されたプロセス寿命なし • ローカルファイルシステムなし • バックグラウンドワーカーなし • 信頼できるメモリ内キャッシュなし

永続性が必要なものはすべてアプリの外にある必要がある： • DB → Neon、PlanetScale、Supabase • 認証 → Clerk、Auth0 • キュー → Upstash、Inngest • キャッシュ → Redis（ホスト型） • 検索 → Algolia • メール → Resend • ストレージ → S3/R2

Next はこれを強制しない — これを前提としている。

サーバーアクションの影響

サーバーアクションは DX 的には素晴らしいが、以下のことももたらす： • フロントエンド/バックエンドの境界を曖昧にする • 明示的なサービスレイヤーを阻害する • 「ここで DB を呼ぶだけ」を普通にする

これは以下の場合にのみうまく機能する： • DB がグローバルに到達可能 • コネクションプーリングが外部で処理される • どこからでも許容可能なレイテンシ

再度 → ホスト型 DB。

エッジランタイムの制限

エッジランタイム： • TCP ソケットなし • ネイティブドライバーなし • 長いクエリなし • ローカル DB なし

突然： • Postgres ドライバーが動作しない • Redis は HTTP ベースである必要がある • すべてが API 形状になる

どの企業がすでに提供しているか？

➡️ サードパーティサービス。

DXインセンティブ

Next エコシステムは以下のために最適化されている： • 「5分で動作する」 • 「インフラ知識不要」 • 「考えずにデプロイ」

つまり： • より少ない決定 • ローカルでのより少ない移動部分 • より多くのマネージドサービス

悪意があるわけではない — DX マキシマリズムだ。

しかしトレードオフは：

「誰かに支払ってステートを保持してもらう。」

経済的な層

Vercel は以下の場合にお金を稼がない： • VPS を実行する • Postgres を自分でホストする • 自分で認証を管理する • バックグラウンドワーカーを実行する

彼らは以下の場合にお金を稼ぐ： • アプリが水平にスケールする • プラットフォーム制限に達する • ネットワーク化されたサービスに依存する • インフラ支出が断片化する

Next の「メタ」パターンは偶然にも意図的にそこへ誘導する。

彼らが悪だからではない — なぜなら：

フレームワークはメンテナーのビジネスモデルを反映する。

経験豊富なエンジニアがこれを間違っていると感じる理由

歴史的に： • バックエンド = もの • サーバーは生きていた • プロセスは持続した • ステートはローカルで制御されていた

Next はこれを逆転させる： • バックエンドは「関数が実行される場所」 • ステートは他人の問題 • インフラはお金がかかるまで抽象化される

VPS ファーストシステムに慣れたエンジニアにとって、これは以下のように感じる： • 脆弱 • 不透明 • 過度にエンジニアリングされている • ベンダーロックインされている

想像しているわけではない。

重要な区別

Next.js ≠ Vercel

Next を実行できる： • VPS 上で • ローカル Postgres で • 自分の Redis で • バックグラウンドワーカーで • エッジランタイムなしで • SaaS 認証なしで

しかし、ドキュメント、例、インフルエンサーによって押し付けられるデフォルトのメンタルモデルは：

「すべてを外部委託する。」

それは選択であり、法律ではない。

正直なトレードオフ

メタNext（SaaSファースト） ✅ 狂気的な DX ✅ 迅速なシッピング ✅ 容易なスケーリング ❌ コストの増加 ❌ ベンダーロックイン ❌ システムの推論が困難

VPSファースト / モノリス ✅ 完全な制御 ✅ 予測可能なコスト ✅ シンプルなメンタルモデル ❌ より多くの運用 ❌ 初期セットアップが遅い

どちらも「正しい」わけではない。異なる段階のために最適化されている。

本当の答え

なぜメタNextがすべてのためにサードパーティサービスに向かうのか？

なぜなら：

プラットフォームは設計上ステートレス
エッジランタイムは従来のインフラを禁止する
DXインセンティブは外部委託に報いる
ビジネスモデルはマネージドサービスと一致する

イデオロギーではない。物理学 + 経済学。

代替アプローチ

Next を UI + ルーティングレイヤーとして使用し、「システム全体」として使用しない。

一般的な合理的なセットアップ： • Next.js（App Router、RSC、shadcn） • VPS バックエンド（Go / Node） • 同じボックス上の Postgres • ローカル Redis • 24時間365日稼働のバックグラウンドワーカー • Next はバックエンドと通信する

これにより得られるもの： • Next の UX の強み • アーキテクチャを放棄することなく

もし望むなら、スケッチできる： • 「アンチメタNext」アーキテクチャ • VPSファースト Next セットアップ • またはハイブリッド：Next フロントエンド + Go バックエンド

どの方向で反逆したいか言ってくれれば 😏

Next.jsがサードパーティサービスに向かわせる理由

目次