Ihr Frontend, Backend und Ihre Datenbank – jetzt in einem Cloudflare Worker

Im September 2024 haben wir die Beta-Unterstützung für das kostenlose Hosten, Speichern und Bereitstellen statischer Assets auf Cloudflare Workers eingeführt – etwas, das bisher nur auf Cloudflare Pages möglich war. Die Möglichkeit, diese Assets – clientseitiges JavaScript, HTML, CSS, Schriftarten und Bilder – zu hosten, war ein wichtiges fehlendes Element für Entwicklerinnen und Entwickler, die eine Full-Stack-Anwendung innerhalb eines einzigen Workers erstellen wollten. 

Heute stellen wir zehn große Verbesserungen für die App-Entwicklung auf Cloudflare vor. Diese neuen Funktionen ermöglichen es Ihnen, alles von einfachen statischen Websites bis hin zu komplexen Full-Stack-Anwendungen direkt auf Cloudflare Workers zu entwickeln und zu hosten:

• Cloudflare Workers bietet jetzt produktionsreife, allgemein verfügbare (GA) Unterstützung für React Router v7 (Remix), Astro, Hono, Vue.js, Nuxt, Svelte (SvelteKit), und mehr. Die allgemeine Verfügbarkeit der Unterstützung für weitere Frameworks einschließlich Next.js, Angular und SolidJS (SolidStart) wird im zweiten Quartal 2025 folgen.

• Sie können komplette Full-Stack-Anwendungen auf Workers ohne Framework entwickeln: Sie können „einfach Vite“ und React zusammen verwenden und eine Backend-API in demselben Worker erstellen. Ein Beispiel finden Sie in unserer Vite + React -Vorlage.

• Der Adapter für Next.js – @opennextjs/cloudflare, der im September 2024 als frühe Alpha-Version eingeführt wurde, ist jetzt v1.0-beta und wird in den kommenden Wochen allgemein verfügbar sein. Diejenigen, die den OpenNext-Adapter verwenden, können auch problemlos ein Upgrade auf die kürzlich angekündigte Next.js Deployments API durchführen.

• Das Cloudflare Vite-Plugin ist jetzt v1.0 und allgemein verfügbar. Das Vite-Plugin ermöglicht es Ihnen, den Entwicklungsserver von Vite in der Workers-Laufzeitumgebung (workerd) zu betreiben. Das bedeutet, dass Sie alle Vorteile von Vite erhalten, einschließlich Hot Module Exchange, und gleichzeitig Funktionen nutzen können, die ausschließlich Workers zur Verfügung stehen (wie Durable Objects).

• Sie können jetzt statische _headers- und _redirects-Konfigurationsdateien für Ihre Anwendungen auf Workers verwenden, was bisher nur auf Pages möglich war. Diese Dateien ermöglichen es Ihnen, einfache Header hinzuzufügen und Umleitungen zu konfigurieren, ohne Worker-Code auszuführen.

• Zusätzlich zu PostgreSQL können Sie jetzt auch von Cloudflare Workers aus über Hyperdrive eine Verbindung zu MySQL-Datenbanken herstellen. Bringen Sie Ihre bestehende Planetscale-, AWS-, GCP-, Azure- oder andere MySQL-Datenbank mit, und Hyperdrive kümmert sich um das Pooling von Verbindungen zu Ihrer Datenbank und eliminiert unnötige Roundtrips durch die Zwischenspeicherung von Abfragen.

• Weitere Node.js-APIs sind in der Workers-Laufzeitumgebung verfügbar, darunter auch APIs der Module crypto, tls, net und dns. Wir haben auch die maximale CPU-Zeit für eine Workers-Anfrage von 30 Sekunden auf 5 Minuten erhöht.

• Sie können jetzt jedes Repository von GitHub oder GitLab einbinden, das eine Worker-Anwendung enthält, und Workers Builds übernimmt automatisch die Bereitstellung der Anwendung als neuen Worker in Ihrem Konto. Workers Builds startet auch viel schneller (um bis zu 6 Sekunden für jeden Build). 

• Sie können Workers Builds jetzt so einrichten, dass sie in nicht in der Produktionsumgebung befindlichen Branches („non-production branches“) ausgeführt werden, und Vorschau-URLs als Kommentar an GitHub gesendet werden. 

• Die Images-Bindung in Workers ist allgemein verfügbar und ermöglicht es Ihnen, flexiblere, programmatische Arbeitsabläufe zu erstellen. 

Dank dieser Verbesserungen können Sie sowohl einfache statische Websites als auch komplexere, serverseitig gerenderte Anwendungen erstellen. Wie bei Pages werden Ihnen nur Kosten berechnet, wenn Ihr Worker-Code ausgeführt wird. Das bedeutet, dass Sie statische Websites kostenlos hosten und bereitstellen können. Wenn Sie ein Rendering auf dem Server durchführen möchten oder eine API erstellen müssen, fügen Sie einfach einen Worker hinzu, der Ihr Backend übernimmt. Und wenn Sie Daten in Ihrer Anwendung lesen oder schreiben müssen, können Sie eine Verbindung zu einer bestehenden Datenbank mit Hyperdrive herstellen oder eine unserer Speicherlösungen verwenden: Workers KV, R2, Durable Objects oder D1. 

Wenn Sie direkt in den Code eintauchen möchten, können Sie eine mit Vite und React erstellte Single-Page-Anwendung bereitstellen, mit der Möglichkeit, über Hyperdrive eine Verbindung zu einer gehosteten Datenbank herzustellen, indem Sie auf die Schaltfläche „Deploy to Cloudflare“ („Bereitstellen über Cloudflare“) klicken: 

Bisher mussten Sie sich entscheiden, ob Sie auf Cloudflare Pages oder Workers entwickeln möchten (oder Pages für einen Teil Ihrer Anwendung und Workers für einen anderen verwenden). Sie mussten also schon zu Beginn alle Anforderungen Ihrer Anwendung kennen – und hoffen, dass sich das Projekt nicht so weiterentwickelt, dass Plattform oder Architektur zur Einschränkung werden. Workers wurde als flexible Plattform konzipiert, die es Entwicklerinnen und Entwicklern ermöglicht, Projekte nach Bedarf weiterzuentwickeln – und so haben wir im Laufe der Jahre daran gearbeitet, Teile von Pages in Workers zu integrieren.  

Da Workers nun sowohl die Bereitstellung statischer Assets als auch serverseitiges Rendern unterstützt, sollten Sie mit Workers beginnen. Cloudflare Pages wird weiterhin unterstützt, aber in Zukunft werden alle unsere Investitionen, Optimierungen und Features der Verbesserung von Workers gewidmet sein. Wir wollen Workers zur besten Plattform für die Entwicklung von Full Stack-Anwendungen machen. Dabei werten wir Ihr Feedback aus, was mit Pages gut funktioniert hat und was wir verbessern könnten. 

Früher bedeutete das Erstellen einer App mit Pages einen einfachen und stark geführten Einstieg – aber sobald die Anwendung komplexer wurde, stieß man schnell an Grenzen. Wenn Sie Durable Objects zur Statusverwaltung verwenden wollten, müssten Sie dafür einen völlig separaten Worker einrichten, was zu einer komplizierten Bereitstellung und mehr Aufwand führt. Außerdem waren Sie auf Echtzeit-Protokolle beschränkt und konnten die Änderungen nur auf einmal implementieren. 

Wenn Sie auf Workers entwickeln, können Sie sofort an jeden anderen Dienst der Entwicklungsplattform (einschließlich Durable Objects, E-Mail-Workers und mehr) anbinden und sowohl Ihr Front-End als auch Ihr Back-End in einem einzigen Projekt verwalten – und das alles mit einer einzigen Bereitstellung. Sie erhalten auch die gesamte Suite von Beobachtungstools für Workers, die in die Plattform integriert sind, wie z. B. Workers Logs. Und wenn Sie Änderungen nur für einen bestimmten Prozentsatz des Traffics vornehmen möchten, können Sie dies mit Gradual Deployments machen.  

Diese neuesten Verbesserungen sind Teil unseres Bestrebens, das Beste von Pages in Workers zu integrieren. So unterstützen wir jetzt beispielsweise statische _headers- und _redirects-Konfigurationsdateien, sodass Sie ein bestehendes Projekt von Pages (oder einer anderen Plattform) ganz einfach auf Workers übertragen können, ohne Ihr Projekt ändern zu müssen. Wir integrieren uns auch direkt in GitHub und GitLab mit Workers Builds und bieten automatische Builds und Bereitstellungen. Ab heute werden die Vorschau-URLs als Kommentar in Ihr Repository zurückgesendet, wobei Feature-Branch-Aliase und Umgebungen in Kürze verfügbar sind. 

Um zu erfahren, wie Sie ein bestehendes Projekt von Pages zu Workers migrieren können, lesen Sie unseren Leitfaden zur Migration. 

Als Nächstes wollen wir uns anschauen, wie man auf Workers Anwendungen mit verschiedenen Rendering-Modi erstellen kann.  

Als kurze Einführung bieten wir hier alle Architekturen und Rendering-Modi an, die von Workers unterstützt werden: 

• Statische Websites: Wenn Sie eine statische Website besuchen, gibt der Server sofort vorgefertigte statische Assets zurück: HTML, CSS, JavaScript, Bilder und Schriftarten. Zur Anfragezeit findet auf dem Server kein dynamisches Rendering statt. Statische Assets werden in der Regel zum Zeitpunkt der Erstellung generiert und direkt von einem CDN aus bereitgestellt, wodurch statische Websites schnell und einfach zwischengespeichert werden können. Dieser Ansatz funktioniert gut für Websites mit Inhalten, die sich selten ändern.

• Single-Page-Anwendungen (SPAs): Wenn Sie eine SPA laden, sendet der Server zunächst eine minimale HTML-Shell und ein JavaScript-Paket (als statische Assets bereitgestellt). Ihr Browser lädt dieses JavaScript herunter, das dann die Darstellung der gesamten Benutzeroberfläche clientseitig übernimmt. Nach dem ersten Laden erfolgt die gesamte Navigation ohne vollständige Seitenaktualisierungen, in der Regel über clientseitiges Routing. Dies schafft ein schnelles, App-ähnliches Erlebnis. 

• Serverseitig gerenderte (SSR) Anwendungen: Wenn Sie eine Website mit SSR zum ersten Mal besuchen, generiert der Server bei Bedarf eine vollständig gerenderte HTML-Seite für diese Anfrage. Ihr Browser zeigt diesen vollständigen HTML-Code sofort an, was zu einer schnellen Ladezeit der ersten Seite führt. Nach dem Laden „hydriert“ JavaScript die Seite und sorgt für Interaktivität. Spätere Navigationen können entweder neue, auf dem Server gerenderte Seiten auslösen oder in vielen modernen Frameworks in ein clientseitiges Rendering ähnlich einem SPA übergehen.

Als Nächstes schauen wir uns an, wie Sie diese Art von Anwendungen auf Workers erstellen können. Wir beginnen mit der Einrichtung Ihrer Entwicklungsumgebung. 

Bevor Sie Ihre Anwendung hochladen, müssen Sie Ihren gesamten clientseitigen Code in ein Verzeichnis mit statischen Assets bündeln. Wrangler bündelt und erstellt Ihren Code, wenn Sie wrangler dev ausführen, aber wir unterstützen jetzt auch Vite mit unserem neuen Vite-Plugin. Dies ist eine großartige Option für diejenigen, die bereits das Build-Tool und den Entwicklungsserver von Vite verwenden – Sie können die Entwicklung (und die Tests mit Vitest) über den Entwicklungsserver von Vite weiterführen und dabei die Workers Laufzeitumgebung nutzen. 

Um mit der Verwendung des Cloudflare Vite-Plugins zu beginnen, können Sie mit Vite und unserem Plugin ein Scaffolding einer React-Anwendung vornehmen, indem Sie Folgendes ausführen: 

npm create cloudflare@latest my-react-app -- --framework=react

Wenn Sie das Projekt öffnen, sollten Sie eine Verzeichnisstruktur wie diese vorfinden: 

...
├── api
│   └── index.ts
├── public
│   └── ...
├── src
│   └── ...
...
├── index.html
├── package.json
├── vite.config.ts
└── wrangler.jsonc

Wenn Sie npm run build ausführen, wird ein neuer Ordner mit dem Namen /dist angezeigt. 

...
├── api
│   └── index.ts
├── dist
│   └── ...
├── public
│   └── ...
├── src
│   └── ...
...
├── index.html
├── package.json
├── vite.config.ts
└── wrangler.jsonc

Das Vite-Plugin informiert Wrangler darüber, dass dieses /dist-Verzeichnis die erstellten statischen Assets des Projekts enthält, zu denen in diesem Fall clientseitiger Code, einige CSS-Dateien und Bilder gehören. 

Nach der Implementierung sieht diese Single-Page-Application-(SPA)-Architektur in etwa so aus: 

Wenn eine Anfrage eingeht, prüft Cloudflare den Pfadnamen und stellt automatisch alle statischen Assets bereit, die diesem Pfadnamen entsprechen. Wenn sich beispielsweise im Verzeichnis Ihrer statischen Assets eine Datei blog.html befindet, wird bei Anfragen an example.com/blog diese Datei bereitgestellt. 

Wenn Sie eine statische Website von einem Statischen Website-Generator (Static Site Generator, SSG) wie Astro erstellen lassen, müssen Sie lediglich eine wrangler.jsonc-Datei (oder wrangler.toml) erstellen und Cloudflare mitteilen, wo sich Ihre erstellten Assets befinden: 

// wrangler.jsonc 

{
  "name": "my-static-site",
  "compatibility_date": "2025-04-01",
  "assets": {
    "directory": "./dist",
  }
}

Sobald Sie diese Konfiguration hinzugefügt haben, können Sie einfach Ihr Projekt erstellen und wrangler deploy ausführen.  Ihre gesamte Website wird dann hochgeladen und ist bereit für den Traffic auf Workers. Nach der Bereitstellung und dem Eintreffen von Anfragen wird Ihre statische Website im Cache des Cloudflare-Netzwerks zwischengespeichert.

Sie können noch heute versuchen, ein neues Astro-Projekt auf Workers zu starten, indem Sie Folgendes ausführen:

npm create cloudflare@latest my-astro-app -- --framework=astro

Unsere anderen unterstützten Frameworks und erste Schritte finden Sie in unseren Framework-Leitfäden. 

Wenn Sie eine Single-Page-Anwendung haben, können Sie den single-page-application-Modus in Ihrer Wrangler Konfiguration explizit aktivieren: 

{
 "name": "example-spa-worker-hyperdrive",
 "main": "api/index.js",
 "compatibility_flags": ["nodejs_compat"],
 "compatibility_date": "2025-04-01",
 },
 "assets": {
   "directory": "./dist",
   "binding": "ASSETS",
   "not_found_handling": "single-page-application"
 },
 "hyperdrive": [
   {
     "binding": "HYPERDRIVE",
     "id": "d9c9cfb2587f44ee9b0730baa692ffec",
     "localConnectionString": "postgresql://myuser:mypassword@localhost:5432/mydatabase"
   }
 ],
 "placement": {
   "mode": "smart"
 }
}

Bei Aktivierung dieser Option geht die Plattform davon aus, dass alle Navigationsanfragen (Anfragen, die einen Sec-Fetch-Modus: navigate-Header enthalten) für statische Assets bestimmt sind und gibt index.html aus, wenn kein passendes statisches Asset gefunden wird. Bei Nicht-Navigationsanfragen (z. B. Datenanfragen), die nicht mit einem statischen Asset übereinstimmen, ruft Cloudflare das Worker-Skript auf. Mit diesem Setup können Sie das Frontend mit React rendern, einen Worker für die Abwicklung der Backend-Vorgänge verwenden und Vite verwenden, um die beiden miteinander zu verbinden. Diese Option eignet sich hervorragend für die Portierung älterer SPAs, die mit create-react-app erstellt wuden – einem Tool, dessen Entwicklung kürzlich eingestellt wurde. 

Noch etwas, das Sie in dieser Wrangler-Konfigurationsdatei beachten sollten: Wir haben eine Hyperdrive-Bindung definiert und Smart Placement aktiviert. Hyperdrive ermöglicht die Nutzung einer bestehenden Datenbank und übernimmt das Pooling von Verbindungen. Damit wird die seit langem bestehende Herausforderung gelöst, Workers (die in einer hochverteilten, serverlosen Umgebung ausgeführt werden) direkt mit traditionellen Datenbanken zu verbinden. Der Grund liegt im Design: Workers werden systembedingt in schlanken V8-Isolaten ohne persistente TCP-Sockets und mit strenger CPU-/Speicherbegrenzung betrieben. Diese Isolierung ist großartig für die Sicherheit und Geschwindigkeit, aber sie erschwert das offene Aufrechterhalten von Datenbankverbindungen. Hyperdrive begegnet diesen Einschränkungen, indem es als „Brücke“ zwischen dem Netzwerk von Cloudflare und Ihrer Datenbank fungiert und sich um die schwere Arbeit der Aufrechterhaltung stabiler Verbindungen oder Pools kümmert, damit Workers diese wiederverwenden können.  Mit aktiviertem Smart Placement wird außerdem gewährleistet, dass Cloudflare bei Anfragen an unseren Worker, die aufgrund großer Entfernung zur Datenbank Latenz verursachen, sowohl den Worker (zuständig für die Datenbankverbindung) als auch die Hyperdrive-„Brücke“ näher zur Datenbank verlagert, was ​​die Umlaufzeiten reduziert. 

SPA-Beispiel: Worker-Code

Sehen wir uns das Beispiel „Bereitstellen über Cloudflare“ am Anfang dieses Blogbeitrags an. In api/index.js haben wir eine API definiert (mit Hono), die über Hyperdrive eine Verbindung zu einer gehosteten Datenbank herstellt. 

import { Hono } from "hono";
import postgres from "postgres";
import booksRouter from "./routes/books";
import bookRelatedRouter from "./routes/book-related";

const app = new Hono();

// Setup SQL client middleware
app.use("*", async (c, next) => {
 // Create SQL client
 const sql = postgres(c.env.HYPERDRIVE.connectionString, {
   max: 5,
   fetch_types: false,
 });

 c.env.SQL = sql;

 // Process the request
 await next();

 // Close the SQL connection after the response is sent
 c.executionCtx.waitUntil(sql.end());
});

app.route("/api/books", booksRouter);
app.route("/api/books/:id/related", bookRelatedRouter);


export default {
 fetch: app.fetch,
};

Nach der Bereitstellung sieht die Architektur unserer Anwendung in etwa so aus: 

Wenn Smart Placement die Platzierung meines Workers näher an meiner Datenbank verschiebt, könnte das folgendermaßen aussehen: 

Wenn Sie das Rendering auf dem Server durchführen möchten, unterstützen wir eine Reihe beliebter Full-Stack-Frameworks. 

Hier ist eine Version unseres vorherigen Beispiels, die jetzt das serverseitige Rendering von React Router v7 verwendet:

Sie können Next.js auch mit dem OpenNext-Adapter oder jedem anderen Framework verwenden, das in unseren Framework-Leitfäden aufgeführt ist. 

Auch bei der Unterstützung von Node.js-APIs haben wir weitere Fortschritte gemacht und kürzlich auch die Unterstützung für die Module crypto, tls, net und dns hinzugefügt. Dadurch können bestehende Anwendungen und Bibliotheken, die auf diese Node.js-Module angewiesen sind, auf Workers ausgeführt werden. Schauen wir uns ein konkretes Beispiel an:

Wenn Sie bisher versucht haben, das mongodb-Paket zu verwenden, ist der folgende Fehler aufgetreten:

Error: [unenv] dns.resolveTxt is not implemented yet!

Dies geschah, wenn mongodb das Modul node:dns verwendete, um einen DNS-Lookup für einen Hostnamen durchzuführen. Selbst wenn Sie dieses Problem vermieden hätten, wäre ein weiterer Fehler aufgetreten, wenn mongodb versucht hätte, node:tls zu verwenden, um eine sichere Verbindung zu einer Datenbank herzustellen.

Jetzt können Sie mongodb wie erwartet verwenden, da node:dns und node:tls unterstützt werden. Das Gleiche gilt für Bibliotheken, die auf node:crypto und node:net angewiesen sind.

Außerdem stellen Workers jetzt Umgebungsvariablen und Secrets über das process.env-Objekt bereit, sofern das Nodejs_compat-Kompatibilitäts-Flag gesetzt ist und das Kompatibilitätsdatum auf den 01.04.2025 oder ein späteres Datum gesetzt ist. Einige Bibliotheken (und Entwicklerinnen bzw. Entwickler) gehen davon aus, dass dieses Objekt mit Variablen gefüllt wird, und verlassen sich bei der Top-Level-Konfiguration darauf. Ohne diese Anpassung konnten Bibliotheken zuvor unerwartet ausfallen, und Entwicklerinnen und Entwickler mussten zusätzliche Logik für die Handhabung von Variablen auf Cloudflare Workers schreiben

Jetzt können Sie einfach wie in Node.js auf Ihre Variablen zugreifen.

const LOG_LEVEL = process.env.LOG_LEVEL || "info";

Wir haben auch die maximale CPU-Zeit pro Worker-Anfrage von 30 Sekunden auf 5 Minuten erhöht. Dadurch können rechenintensive Vorgänge länger ohne Timeouts ausgeführt werden. Angenommen, Sie möchten das neu unterstützte node:crypto-Modul verwenden, um eine sehr große Datei zu hashen, so können Sie dies jetzt auf Workers machen, ohne sich bei CPU-intensiven Vorgängen auf externe Rechenleistung verlassen zu müssen.

Wir haben auch Workers Builds verbessert, die es Ihnen ermöglichen, ein Git-Repository mit Ihrem Worker zu verbinden, sodass Sie bei jeder übertragenen Änderung automatische Builds und Bereitstellungen erhalten. Workers Builds wurde während des Builder Day 2024 eingeführt und erlaubte Ihnen zunächst nur, ein Repository mit einem bestehenden Worker zu verbinden. Jetzt können Sie ein Repository aufbauen und es sofort als neuen Worker bereitstellen. Das reduziert die Setup-Bemühungen und Schaltflächenklicks, die zum Übertragen eines Projekts erforderlich sind. Wir haben die Performance von Workers Builds verbessert, indem wir die Latenzzeit von Build-Starts um 6 Sekunden reduziert haben — sie beginnen jetzt im Durchschnitt innerhalb von 10 Sekunden. Wir haben auch die Reaktionsfähigkeit der API verbessert und dank Smart Placement eine 7-fache Verbesserung der Latenzzeit erreicht. 

• Hinweis: Am 2. April 2025 ging Workers Builds zu einem neuen Preismodell über, wie beim Builder Day 2024 angekündigt. Benutzer des Free-Tarifs sind jetzt auf 3.000 Minuten Erstellungszeit begrenzt, und Benutzer des Workers Paid-Abonnements erhalten ein neues nutzungsbasiertes Modell mit 6.000 Freiminuten, danach fallen Kosten von 0,0005 USD pro Build-Minute an. Um gleichzeitige Builds besser zu unterstützen, erhalten kostenpflichtige Tarife jetzt auch sechs (6) gleichzeitige Builds, was das Arbeiten mit mehreren Projekten und Monorepos erleichtert. Weitere Informationen zu den Preisen finden Sie in der Dokumentation.

Sie können Workers Builds auch so einrichten, dass sie in nicht in der Produktionsumgebung eingesetzten Branches ausgeführt werden, und Vorschau-URLs werden als Kommentar an GitHub zurückgesendet. 

Letzte Woche haben wir einen Blog-Beitrag verfasst, in dem wir darauf eingehen, wie die Images-Bindung flexiblere, programmatische Workflows zur Bildoptimierung ermöglicht.

Bisher konnten Sie auf Funktionen zur Bildoptimierung zugreifen, indem Sie fetch() in Ihrem Worker aufruften. Für diese Methode muss das Originalbild über die URL abrufbar sein. Es kann jedoch vorkommen, dass Bilder nicht über eine URL zugänglich sind, z. B. wenn Sie von Nutzern hochgeladene Bilder komprimieren möchten, bevor sie in Ihren Speicher hochgeladen werden. Mit der Images-Bindung können Sie ein Bild direkt optimieren, indem Sie seinen Body als Byte-Stream bearbeiten.

Weitere Informationen finden Sie in unserer Anleitung zur Transformierung eines Bildes, bevor es auf R2 hochgeladen wird.

Wir sind gespannt darauf, was Sie entwickeln werden, und konzentrieren uns auf neue Funktionen und Verbesserungen, die die Erstellung von Anwendungen auf Workers erleichtern werden. Ein Großteil dieser Arbeit wurde durch Feedback aus der Community noch besser gemacht, und wir ermutigen alle, sich in unserem Discord an der Diskussion zu beteiligen. 

Hilfreiche Ressourcen für den Einstieg:

• Framework-Anleitungen 

• Leitfaden zur Migration 

• Dokumentation statischer Assets 

• Dokumentation zum Cloudflare Vite-Plugin