Edge- und Node.js-Laufzeitumgebungen
Im Kontext von Next.js bezieht sich Runtime auf die Sammlung von Bibliotheken, APIs und allgemeinen Funktionen, die Ihrem Code während der Ausführung zur Verfügung stehen.
Auf dem Server gibt es zwei Runtimes, in denen Teile Ihres Anwendungscodes gerendert werden können:
- Die Node.js-Runtime (Standard) hat Zugriff auf alle Node.js-APIs und kompatible Pakete aus dem Ökosystem.
- Die Edge-Runtime basiert auf Web-APIs.
Unterschiede zwischen den Runtimes
Bei der Wahl einer Runtime gibt es viele Aspekte zu berücksichtigen. Diese Tabelle zeigt die wichtigsten Unterschiede auf einen Blick. Für eine detailliertere Analyse der Unterschiede lesen Sie die folgenden Abschnitte.
| Node | Serverless | Edge | |
|---|---|---|---|
| Cold Boot | / | Normal | Niedrig |
| HTTP-Streaming | Ja | Ja | Ja |
| IO | Alle | Alle | fetch |
| Skalierbarkeit | / | Hoch | Am höchsten |
| Sicherheit | Normal | Hoch | Hoch |
| Latenz | Normal | Niedrig | Am niedrigsten |
| npm-Pakete | Alle | Alle | Eine kleinere Teilmenge |
| Statisches Rendering | Ja | Ja | Nein |
| Dynamisches Rendering | Ja | Ja | Ja |
Daten-Revalidierung mit fetch | Ja | Ja | Ja |
Edge-Runtime
In Next.js ist die schlanke Edge-Runtime eine Teilmenge der verfügbaren Node.js-APIs.
Die Edge-Runtime ist ideal, wenn Sie dynamische, personalisierte Inhalte mit geringer Latenz und kleinen, einfachen Funktionen bereitstellen müssen. Die Geschwindigkeit der Edge-Runtime ergibt sich aus der minimalen Ressourcennutzung, was jedoch in vielen Szenarien einschränkend sein kann.
Beispielsweise darf der in der Edge-Runtime ausgeführte Code auf Vercel nicht zwischen 1 MB und 4 MB überschreiten. Dieses Limit umfasst importierte Pakete, Schriftarten und Dateien und variiert je nach Bereitstellungsinfrastruktur. Darüber hinaus unterstützt die Edge-Runtime nicht alle Node.js-APIs, was bedeutet, dass einige npm-Pakete möglicherweise nicht funktionieren. Zum Beispiel Fehler wie "Module not found: Can't resolve 'fs'" oder ähnliche. Wir empfehlen die Verwendung der Node.js-Runtime, wenn Sie diese APIs oder Pakete benötigen.
Node.js-Runtime
Die Verwendung der Node.js-Runtime gewährt Ihnen Zugriff auf alle Node.js-APIs und alle npm-Pakete, die darauf basieren. Allerdings ist der Start nicht so schnell wie bei Routen, die die Edge-Runtime verwenden.
Die Bereitstellung Ihrer Next.js-Anwendung auf einem Node.js-Server erfordert die Verwaltung, Skalierung und Konfiguration Ihrer Infrastruktur. Alternativ können Sie Ihre Next.js-Anwendung auf einer serverlosen Plattform wie Vercel bereitstellen, die dies für Sie übernimmt.
Serverlose Node.js
Serverless ist ideal, wenn Sie eine skalierbare Lösung benötigen, die komplexere Rechenlasten als die Edge-Runtime bewältigen kann. Bei Serverless Functions auf Vercel beträgt die maximale Codegröße beispielsweise 50 MB, einschließlich importierter Pakete, Schriftarten und Dateien.
Der Nachteil im Vergleich zu Routen mit Edge besteht darin, dass Serverless Functions hunderte von Millisekunden benötigen können, um hochzufahren, bevor sie Anfragen verarbeiten. Abhängig vom Datenverkehr Ihrer Website kann dies häufig vorkommen, da die Funktionen nicht immer "warm" sind.
Weitere Informationen zu den verfügbaren APIs finden Sie in der Node.js-Dokumentation und den Edge-Dokumenten. Beide Runtimes können je nach Bereitstellungsinfrastruktur auch Streaming unterstützen.
Client-seitiges Rendering (CSR)
Erfahren Sie, wie Sie Client-seitiges Rendering im Pages Router implementieren.
Datenabruf
Next.js ermöglicht den Datenabruf auf verschiedene Arten, mit Pre-Rendering, Server-seitigem Rendering oder Static-Site Generation sowie Incremental Static Regeneration. Erfahren Sie, wie Sie Ihre Anwendungsdaten in Next.js verwalten.