- Der JavaScript-/WASM-Runtime-Code, der tatsächlich bei Cloudflare Workers verwendet wird
- Nur teilweise geändert, damit er auf andere Umgebungen portiert werden kann
- Der Name stammt vom
-d-„daemon“ eines Unix-Servers, also „worker dee“
Einsatzzwecke
- Workers können selbst gehostet werden. Es ist auch einfach ein Webserver, der per API genutzt werden kann. Lässt sich in jeder Umgebung leicht einsetzen
- Verwendung für lokale Entwicklung und Tests
- Programmierbarer Proxy (Forward & Reverse). Anfragen/Antworten können in JavaScript abgefangen und verarbeitet werden
What it is
- Server-first: Viele JS-/WASM-Runtimes sind vielseitig einsetzbar, workerd konzentriert sich jedoch ausschließlich auf Server. Insbesondere auf HTTP-Server
- Web standard APIs: Stellt Standard-APIs bereit wie im Webbrowser (Fetch, URL, WebCrypto usw.). Das heißt, hier entwickelter Code kann auch in den Browser portiert werden
- Nanoservices: Jetzt über Microservices hinaus zu Nanoservices!
- Nanoservices sind ein neues Modell, das die Vorteile unabhängiger Deployments mit nur dem Overhead eines Bibliotheksfunktionsaufrufs verbindet
- Mit workerd können viele Worker im selben Prozess konfiguriert werden; jeder Worker läuft isoliert, kann aber auch mit anderen kommunizieren
- Homogeneous deployment: Früher musste ein bestimmter Service in einem bestimmten Container laufen, mit workerd können alle Maschinen alle Services ausführen
- Capability bindings: Saubere Konfiguration und garantierte SSRF-Sicherheit
- Always backwards compatible: Abwärtskompatibilität ist jederzeit gewährleistet
What it's not
- workerd is not a Secure Sandbox: Es kann bösartiger Code ausgeführt werden. Um das zu verhindern, ist eine zusätzliche Sandboxing-Schicht erforderlich
- workerd is not an independent project: Kernbestandteil und Teil von Cloudflare Workers. Externe Commits werden zwar angenommen, Zusagen dazu sind aber schwierig.
- workerd is not an off-the-shelf edge compute platform: Nicht der gesamte Workers-Service
2 Kommentare
Das ist genau das, was ich ausprobieren wollte, sobald es veröffentlicht wird – ohho.
Ich habe mich gefragt, was das bedeutet, aber offenbar war damit gemeint, dass man bei der Entwicklung im zuvor erläuterten Nanoservice-(Functions-)Ansatz einfach alle Nanoservices auf einer Maschine bereitstellen kann (weil der Overhead gering genug ist) und bei Bedarf einfach identische Maschinen hinzufügt, sodass keine komplexe Bereitstellungskonfiguration nötig ist.