Why Next.js Pushes You Toward Third-Party Services

Published:  at 

Table of Contents

Open Table of Contents

The Core Reason

Next.js is optimised for stateless, distributed, edge-first infrastructure.

Once you accept that premise, a bunch of things become inevitable: • Local state → bad • Long-lived processes → bad • In-memory anything → bad • Stateful servers → bad • “Just run Postgres next to the app” → discouraged

So where does that stuff go?

➡️ Third-party services.

Why This Bias Exists

Vercel’s Platform Constraints

Next.js is built by Vercel, and Vercel’s platform is: • serverless • horizontally scaled • ephemeral • edge-distributed

That means: • no guaranteed process lifetime • no local filesystem • no background workers • no reliable in-memory cache

So anything that needs persistence must live outside your app: • DB → Neon, PlanetScale, Supabase • Auth → Clerk, Auth0 • Queues → Upstash, Inngest • Cache → Redis (hosted) • Search → Algolia • Email → Resend • Storage → S3/R2

Next doesn’t force this — it assumes it.

Server Actions Impact

Server Actions are brilliant DX-wise, but they also: • blur frontend/backend boundaries • discourage explicit service layers • make “just call the DB here” normal

That works great only if: • DB is globally reachable • connection pooling is handled externally • latency is acceptable from anywhere

Again → hosted DBs.

Edge Runtime Limitations

Edge runtime: • no TCP sockets • no native drivers • no long queries • no local DB

So suddenly: • Postgres drivers don’t work • Redis must be HTTP-based • Everything becomes API-shaped

Which companies already offer?

➡️ Third-party services.

DX Incentives

The Next ecosystem optimises for: • “works in 5 minutes” • “no infra knowledge required” • “deploy without thinking”

That means: • fewer decisions • fewer moving parts locally • more managed services

It’s not malicious — it’s DX maximalism.

But the tradeoff is:

“Pay someone else to hold your state.”

The Economic Layer

Vercel doesn’t make money when you: • run a VPS • host Postgres yourself • manage your own auth • run background workers

They make money when: • your app scales horizontally • you hit platform limits • you rely on networked services • your infra spend becomes fragmented

Next’s “meta” patterns accidentally-on-purpose nudge you there.

Not because they’re evil — but because:

frameworks reflect the business model of their maintainers.

Why It Feels Wrong to Experienced Engineers

Because historically: • backend = a thing • servers lived • processes persisted • state was local and controlled

Next flips that: • backend is “wherever the function runs” • state is someone else’s problem • infra is abstracted until it costs money

To engineers used to VPS-first systems, this feels: • fragile • opaque • over-engineered • vendor-locked

You’re not imagining it.

The Crucial Distinction

Next.js ≠ Vercel

You can run Next: • on a VPS • with local Postgres • with your own Redis • with background workers • without edge runtime • without SaaS auth

But the default mental model pushed by docs, examples, and influencers is:

“Outsource everything.”

That’s a choice, not a law.

The Honest Tradeoff

Meta Next (SaaS-first) ✅ insane DX ✅ fast to ship ✅ easy scaling ❌ cost creep ❌ vendor lock-in ❌ harder to reason about systems

VPS-first / monolith ✅ full control ✅ predictable costs ✅ simpler mental model ❌ more ops ❌ slower initial setup

Neither is “right”. They optimise for different stages.

The Real Answer

Why is meta Next geared towards third-party services for everything?

Because:

  1. The platform is stateless by design
  2. The edge runtime forbids traditional infra
  3. DX incentives reward outsourcing
  4. The business model aligns with managed services

Not ideology. Physics + economics.

The Alternative Approach

Use Next as a UI + routing layer, not as “the whole system”.

Common sane setup: • Next.js (App Router, RSC, shadcn) • VPS backend (Go / Node) • Postgres on the same box • Redis locally • Background workers alive 24/7 • Next talks to your backend

That gives you: • Next’s UX strengths • without surrendering architecture

If you want, I can sketch: • “anti-meta Next” architecture • VPS-first Next setup • or hybrid: Next frontend + Go backend

Just say which direction you want to rebel in 😏