Next.js vs. Express: Nur eines von beiden rendert

Diese beiden werden verglichen, weil beide Node sind und beide HTTP bedienen - und damit endet die Ähnlichkeit ungefähr. Express ist ein minimales HTTP-Framework, das Sie zusammensetzen. Next.js ist ein Rendering-Framework, das zufällig einen Server enthält.

Die Entscheidung ist eigentlich kein Vergleich. Es ist eine Frage danach, was Sie bauen.

Wenn Sie eine API bauen und sonst nichts

Nehmen Sie Express, oder Fastify, oder Hono. Next.js-Route-Handler gibt es und sie funktionieren, aber Sie nähmen ein Rendering-Framework, einen Build-Schritt, einen dateisystembasierten Router und eine React-Abhängigkeit in Kauf - für einen Dienst, der nichts rendert.

Konkret bleibt Express besser, wenn Ihre API Folgendes hat:

• Externe Konsumenten. Versionierte Routen, API-Schlüssel, dokumentierte Verträge.
• Eine eigene Middleware-Kette. Rate Limiting, Request-Validierung, eigene Authentifizierung, Logging, das Ihnen gehört.
• Irgendetwas Langlebiges. WebSockets, Server-Sent Events, Verbindungen, die einen Request überdauern.
• Deployment-Einschränkungen. Ein schlichter Node-Prozess ist einfacher zu betreiben auf Infrastruktur, die Meinungen hat.

Wenn Sie Seiten rendern, bauen Sie es nicht selbst

Die Gegenrichtung ist stärker und weniger offensichtlich.

Teams, die mit Express beginnen und React obendrauf setzen, schreiben am Ende von Hand, was Next.js bereits entschieden hat: Routing, Code Splitting, serverseitiges Datenladen, Streaming, die Client-Bundle-Grenze, Bildhandling, Caching. Jedes davon ist eine Woche. Zusammen sind sie ein Framework - und es wird ein schlechteres, weil es ein Nebenprojekt ist statt das Produkt.

Wenn Ihre Anwendung Seiten hat, ist das Argument für Express das Argument dafür, ein eigenes Framework zu schreiben. Das ist gelegentlich richtig und meistens nicht.

Wo Route Handler wirklich genügen

Für eine API, die nur Ihr eigenes Frontend nutzt, erledigen Next.js-Route-Handler die Aufgabe:

// app/api/products/route.ts
export async function GET(request: Request) {
  const products = await db.product.findMany();
  return Response.json(products);
}

Ein Deployment, eine Codebasis, geteilte Typen zwischen API und den Komponenten, die sie aufrufen. Für die meisten Produktanwendungen ist das die richtige Menge Maschinerie.

Gut zu wissen: Für Daten, die Ihre eigenen Seiten brauchen, benötigen Sie oft gar keine Route. Eine Server Component kann direkt abfragen, und eine Server Action kann mutieren - der Umweg über die eigene HTTP-API ist eine Gewohnheit aus einer clientseitig gerenderten Architektur.

Die Anordnung, bei der die meisten Teams landen

Express - oder Fastify, oder ein Go-Dienst, oder Laravel - trägt die Geschäftslogik und die Jobs. Next.js trägt das Frontend. Sie sprechen über HTTP.

Das ist dieselbe Schlussfolgerung wie bei Next.js gegen Laravel, aus demselben Grund: Render-Pfad und Geschäftslogik sind verschiedene Probleme, und Frameworks sind jeweils in einem davon gut.

Was Sie nicht tun sollten

Einen Custom-Express-Server vor Next.js. Es wird unterstützt und deaktiviert die automatische statische Optimierung für die Routen, die er bedient - also für das meiste, weswegen Sie gekommen sind. Wenn Sie einen Proxy brauchen, stellen Sie ihn vor beide Prozesse statt in einen von ihnen.

Eine Express-Middleware-Kette nach proxy.ts portieren. Die Konvention, die Middleware in 16 ersetzt hat, läuft auf Node, ist nicht konfigurierbar und läuft bei Requests, die Sie nicht vorgesehen hatten. Sie ist für Routing-Entscheidungen da, nicht für eine Request-Pipeline.