Cloudflare Workers können jetzt in Python geschrieben werden

 (blog.cloudflare.com)
3 Punkte von GN⁺ 2024-04-03 | 1 Kommentare | Auf WhatsApp teilen
  • Cloudflare Workers unterstützt das Schreiben in Python nun als Open Beta und erweitert das bisher JavaScript-zentrierte Modell, indem Pyodide direkt in die Open-Source-Workers-Runtime workerd integriert wird
  • Python Workers unterstützen bestehende Bindings wie Vectorize, Workers AI, R2 und Durable Objects vom ersten Tag an und können einige Python-Pakete wie FastAPI, Langchain und Numpy importieren
  • Grundlage der Implementierung ist Pyodide, ein WebAssembly-Port von CPython; über FFI zwischen JavaScript und Python werden Request, Response, Fetch API und Cloudflare-Ressourcen-Bindings in Python-Code genutzt
  • Cloudflare führt Imports zum Zeitpunkt des Deployments aus und erstellt einen Snapshot des linearen WebAssembly-Speichers, um die Initialisierungskosten von Pyodide und Paketen zu senken; der Cold Start eines einfachen Python Workers sinkt dadurch auf unter eine Sekunde
  • Python-Versionen sowie Updates für Pyodide und Pakete werden über Compatibility Dates und Compatibility Flags verwaltet; Worker, die auf einem Python-Release bleiben, dessen fünfjähriger Supportzeitraum abgelaufen ist, werden automatisch auf das nächstältere Python-Release verschoben

Open Beta für Python Workers

  • Python Workers sind in Cloudflare Workers als Open Beta verfügbar
  • Anders als bei der bisherigen Unterstützung für Sprachen neben JavaScript wird die Python-Implementierung direkt in die workerd-Runtime integriert
  • Zu den Cloudflare-Bindings, die vom ersten Tag an unterstützt werden, gehören:
  • Python Workers können einige beliebte Python-Pakete wie FastAPI, Langchain und Numpy importieren
  • Es ist kein separater Build-Schritt und keine externe Toolchain erforderlich

Warum reines Kompilieren nach WebAssembly nicht ausreichte

  • Workers unterstützen WebAssembly seit 2018, und jeder Worker läuft in einem V8-Isolate, also in derselben JavaScript-Engine wie Chrome
  • Grundsätzlich konnten viele Sprachen, darunter Python, in Workers ausgeführt werden, wenn sie zuvor nach WebAssembly oder JavaScript kompiliert wurden
  • Reale Anwendungen brauchen mehr als ein „hello world“; wichtig ist die Unterstützung des Paket-Ökosystems, das Entwickler gewohnt sind
  • Python Workers sind eine frühe Form des Versuchs, Sprachen neben JavaScript in Workers als First-Class-Citizens zu unterstützen

Ausführungsablauf eines Python Workers

  • Da Pyodide in workerd integriert ist, kann ein Python Worker Anfragen über einen on_fetch-Handler verarbeiten
  • In wrangler.toml wird eine .py-Datei als main angegeben und compatibility_flags = ["python_workers"] gesetzt
  • Beim Ausführen von npx wrangler@latest dev übernimmt die Workers-Runtime Folgendes:
    • Sie bestimmt anhand des compatibility date die benötigte Pyodide-Version
    • Sie erstellt ein Isolate für den Worker und injiziert Pyodide automatisch
    • Sie stellt Pyodide den Python-Code bereit
  • Die Python-Ausführungsumgebung wird intern gehandhabt und wie bei JavaScript Workers von der Plattform bereitgestellt

Warum Pyodide zu Workers passt

  • Pyodide ist eine Implementierung, die CPython nach WebAssembly portiert, und interpretiert Python-Code, ohne ihn vorab in ein anderes Format zu kompilieren
  • Es stellt den Großteil der Python-Standardbibliothek bereit sowie ein Foreign Function Interface (FFI), mit dem JavaScript-APIs aus Python heraus aufgerufen werden können
  • Der Kerninterpreter und die einzelnen nativen Python-Module werden als separate WebAssembly-Module gebaut und sind so konzipiert, dass sie zur Laufzeit dynamisch gelinkt werden können
  • Mehrere Workers, die auf derselben Maschine laufen, können den Code-Footprint der Module teilen; das ist in Cloudflares Umgebung wichtig, in der Tausende Workers pro Maschine ausgeführt werden
  • Die meisten Sprachen mit WebAssembly-Ziel unterstützen dynamisches Linken noch nicht, sodass jede Anwendung häufig ihre eigene Kopie der Sprach-Runtime enthält

Pyodide und dynamisches Linken in WebAssembly

  • WebAssembly ist eine von der Host-Runtime getrennte Sandbox-Umgebung; Arbeiten jenseits reiner Berechnungen, etwa das Lesen von Dateien, müssen daher von der Runtime-Umgebung bereitgestellt und vom Modul importiert werden
  • Das WebAssembly-Target von LLVM ist in drei Varianten unterteilt:
    • wasm32-unknown-unknown: Stellt weder eine C-Standardbibliothek noch ein System-Call-Interface bereit
    • wasm32-wasi: Nutzt standardisierte System-Interfaces, die von einer WASI-Runtime implementiert werden
    • wasm32-unknown-emscripten: Definiert die benötigten Imports und gibt eine JavaScript-Bibliothek mit aus, die diese implementiert
  • Pyodide verwendet Emscripten, um den CPython-Interpreter, das Python-JavaScript-FFI und nach WebAssembly kompilierte Python-Pakete von Drittanbietern bereitzustellen
  • Von diesen Targets unterstützt derzeit nur Emscripten dynamisches Linken
  • WASI unterstützt die von CPython verwendeten dynamischen Link-Abstraktionen dlopen/dlsym noch nicht

FFI als Brücke zwischen Python und JavaScript

  • Ein Beispiel für einen Python Worker importiert mit from js import Response das JavaScript-Response-Objekt
  • Das FFI von Pyodide ermöglicht Python den Zugriff auf alle JavaScript-Funktionen und verringert so das Risiko, dass Python Workers funktional hinter JavaScript Workers zurückbleiben
  • Unveränderliche Typen wie Strings und Zahlen werden zwischen beiden Sprachen transparent konvertiert, veränderliche Objekte werden in passende Proxys gewrappt
  • Wenn ein JavaScript-Objekt an Python übergeben wird, prüft Pyodide, welche JavaScript-Protokolle dieses Objekt unterstützt, und erzeugt dynamisch eine Klasse, die die entsprechenden Python-Protokolle implementiert
    • Unterstützt es das JavaScript-Iterationsprotokoll, unterstützt es auch das Python-Iterationsprotokoll
    • Ist es ein Promise oder thenable, wird es in Python zu einem awaitable Objekt
  • Auch im Request-Handling wird das eingehende JavaScript-Request-Objekt in einen für Python-Code zugänglichen JsProxy gewrappt, und der Rückgabewert des Python-Handlers wird in ein JavaScript-Response-Objekt konvertiert

Dynamisches Linken und Python-Pakete

  • Viele Python-Pakete binden native Bibliotheken über C-FFI ein; damit sie in der Workers-Runtime funktionieren, müssen diese Bibliotheken nach WebAssembly kompiliert sein
  • Pyodide wird mit Emscripten gebaut, überschreibt Pythons C-FFI und lädt WebAssembly-Module, die von der Workers-Runtime bereitgestellt werden, wenn ein Paket versucht, native Bibliotheken zu laden
  • Dynamisches Linken ermöglicht es Pyodide, mehrere Python-Pakete mit Abhängigkeiten zu nativen Bibliotheken zu unterstützen
  • Beim statischen Linken muss der gesamte benötigte Code vor dem Start der Binärausführung geladen werden; beim dynamischen Linken fallen die Kosten erst bei Bedarf an
  • Workers erzeugt zur Laufzeit für jeden Worker ein Dateisystem, das wie eine Python-Distribution aussieht; die zugrunde liegenden Dateien werden jedoch zwischen Workers geteilt
  • Derzeit werden Dateien zwar zwischen Workers geteilt, aber für jedes neue Isolate kopiert; künftig könnten mit Copy-on-Write-Techniken mehr zugrunde liegende Ressourcen gemeinsam genutzt werden

Unterstützung für HTTP-Client- und Server-Bibliotheken

  • Python bietet viele HTTP-Client-Bibliotheken wie httpx, urllib3 und requests, diese funktionieren in Pyodide jedoch nicht von Haus aus
  • Diese Bibliotheken verwenden rohe Sockets, und das Sicherheitsmodell des Browsers sowie CORS erlauben dies nicht; in der Workers-Runtime ist daher ein anderer Ansatz nötig

  • Asynchrone Clients

    • Bibliotheken, die asynchrone Requests unterstützen, wie aiohttp und httpx, können die Fetch API von Workers verwenden
    • Cloudflare patcht die Bibliotheken über Pyodide FFI so, dass sie die Fetch API von JavaScript nutzen
    • Der httpx-Patch besteht aus weniger als 100 Zeilen Code

  • Synchrone Clients und Grenzen

    • Viele Python-APIs sind synchron, und in diesem Fall kann die asynchrone Fetch API nicht direkt verwendet werden
    • In urllib3 wurden Beiträge für Pyodide-Browser-Support aufgenommen, die Atomics.wait() und einen Fetch-Worker-Thread oder synchrones XMLHttpRequest verwenden
    • Cloudflare Workers unterstützt derzeit keine Worker Threads und kein synchrones XMLHttpRequest, daher funktionieren diese beiden Ansätze in Python Workers nicht
    • Synchrone Requests werden derzeit nicht unterstützt

  • WebAssembly Stack Switching

    • Für WebAssembly gibt es einen Stage-3-Vorschlag, der Stack Switching hinzufügt, und in V8 existiert eine Implementierung
    • Pyodide-Contributors fügen seit September 2022 Unterstützung für Stack Switching hinzu, die nahezu fertig ist
    • Wenn diese Unterstützung verfügbar ist, kann run_sync von Pyodide blockieren, bis ein awaitable abgeschlossen ist; damit entsteht ein Weg zur Unterstützung synchroner Requests

FastAPI und ASGI

  • FastAPI ist eine häufig verwendete Bibliothek zum Definieren von Python-Servern und nutzt das ASGI-Protokoll
  • FastAPI-Anwendungen lesen oder schreiben nicht direkt auf Sockets; in der Regel übernimmt ein ASGI-Server wie uvicorn die Verarbeitung roher Sockets
  • Dank dieser Struktur kann FastAPI auf Cloudflare Workers laufen, ohne FastAPI selbst zu patchen oder auszutauschen
  • Es genügt, uvicorn durch einen ASGI-Server zu ersetzen, der innerhalb von Workers ausgeführt werden kann
  • Eine erste Implementierung befindet sich in asgi.py von workerd und ist im von Cloudflare gepflegten Pyodide-Fork enthalten
  • Cloudflare plant, die Funktionalität auszubauen und Testabdeckung hinzuzufügen, bevor die Änderungen upstream in Pyodide eingebracht werden

Python-Pakete importieren

  • Python Workers unterstützen einige Python-Pakete, die Pyodide direkt bereitstellt
  • Zu den unterstützten Paketen gehören numpy, httpx, FastAPI und Langchain
  • Um Pakete zu importieren, fügt man den Paketnamen ohne Versionsnummer in requirements.txt hinzu
  • Die jeweilige Paketversion wird direkt von Pyodide bereitgestellt
  • Derzeit können Pakete in der lokalen Entwicklung verwendet werden; in einigen Wochen soll es möglich sein, Workers mit in requirements.txt definierten Abhängigkeiten zu deployen
  • Cloudflare pflegt einen eigenen Pyodide-Fork, um Patches speziell für die Workers-Runtime bereitzustellen, und will die Änderungen upstream in Pyodide einbringen

Cold Starts und Memory Snapshots

  • Pyodide selbst ist 6,4 MB groß, und auch Python-Pakete können groß sein
  • Wenn Pyodide unverändert in einen Worker gepackt und zu Cloudflare hochgeladen wird, steigen die Kosten für das Laden eines neuen Isolates, wodurch Cold Starts langsamer werden
  • Auf einem schnellen Computer und mit guter Netzwerkverbindung benötigt Pyodide im Browser etwa 2 Sekunden für die Initialisierung, davon entfallen 1 Sekunde auf das Netzwerk und 1 Sekunde auf die CPU
  • Bei npx wrangler@latest deploy läuft der Deployment-Prozess wie folgt ab
    • Wrangler lädt den Python-Code und requirements.txt in die Workers API hoch
    • Die Workers-Runtime validiert den Python-Code und die Abhängigkeiten
    • Sie erstellt ein neues Isolate und injiziert Pyodide sowie die angegebenen Pakete automatisch
    • Sie scannt und führt die Import-Anweisungen des Worker-Codes aus und erstellt anschließend einen Snapshot des linearen WebAssembly-Speichers des Workers
    • Dieser Snapshot und der Python-Code werden im Cloudflare-Netzwerk deployt
    • Wie bei einem JavaScript Worker wird der Top-Level-Scope ausgeführt
  • Wenn eine Anfrage eingeht, wird dieser Snapshot geladen und der Worker im Isolate gebootstrapt, wodurch die teuren Initialisierungskosten vermieden werden
  • Der Cold Start eines einfachen Python Workers sinkt auf unter 1 Sekunde

  • Wiederverwendung von Snapshots

    • Der derzeit beim Upload eines Python Workers erzeugte Memory Snapshot ist spezifisch für diesen Worker und kann nicht geteilt werden, auch wenn er zu großen Teilen mit anderen Python Workers identisch ist
    • Cloudflare geht davon aus, vorab einen einzelnen gemeinsamen Snapshot erstellen und ihn in einen Pool von pre-warmed isolates laden zu können, in denen die Pyodide-Runtime bereits geladen ist
    • Mit diesem Ansatz würden Python Workers einem Modell näherkommen, bei dem die Runtime wie bei JavaScript Workers on-demand bereitgestellt wird
    • Cloudflare sieht die Wiederverwendung von Snapshots als wichtigsten Hebel, um Cold Starts im restlichen Jahr 2024 weiter zu reduzieren

Verwaltung von Python-Versionen mit Compatibility Dates

  • Cloudflare Workers folgen einem Modell, bei dem erwartet wird, dass ein einmal deployter Worker auch ohne Updates weiterläuft
  • Diese Stabilität wird über Compatibility Dates und Compatibility Flags bereitgestellt
  • In Python haben Pyodide und CPython jeweils eigene Versionen, und neue Versionen können Breaking Changes enthalten
  • Neue Python-Versionen werden jedes Jahr im August veröffentlicht, neue Pyodide-Versionen folgen sechs Monate später
  • Neue Pyodide-Versionen werden beim Hinzufügen zu Workers hinter einem Compatibility Flag platziert und erst nach dem angegebenen Compatibility Date aktiviert
  • Python-Releases haben einen Supportzeitraum von 5 Jahren, und für Python-Versionen außerhalb dieses Zeitraums werden keine Sicherheits-Patches angewendet
  • Python Workers, die auch nach 5 Jahren auf einem alten Python-Release bleiben, werden automatisch auf das nächstältere Python-Release verschoben
  • Cloudflare erwartet, dass Python Workers in den meisten Fällen problemlos weiterlaufen, empfiehlt aber, das compatibility date regelmäßig zu aktualisieren, damit man innerhalb des Supportzeitraums bleibt
  • Auch zwischen Python-Releases sollen Pakete nach demselben Opt-in-Prinzip aktualisiert und hinzugefügt werden; ein Beispiel-Flag hat die Form python_3.17_packages_2025_03_01

Bindings von Python Workers

  • Dank Pyodide FFI kann Python direkt auf JavaScript-Objekte, -Methoden und -Funktionen zugreifen
  • Durch diese Struktur werden alle binding APIs für Cloudflare-Ressourcen vom ersten Tag an in Python Workers unterstützt
  • Das env-Objekt eines Python-Handlers ist ein JavaScript-Objekt; Pyodide stellt eine Proxy-API bereit, die die Typumwandlung zwischen den Sprachen übernimmt
  • Für einen KV-Namespace lassen sich mit await auf env.FOO.put() und env.FOO.get() in Python Werte schreiben und lesen
  • Auch Web APIs können auf dieselbe Weise verwendet werden; JavaScript-Globals wie Response können aus dem Modul js importiert werden

Plan für stärker Python-typische APIs

  • Cloudflare erkennt, dass Formen wie from js import Response nicht besonders Python-typisch sind, und plant, für Python Workers idiomatischere APIs bereitzustellen
  • Das 2021 veröffentlichte workers-rs bot für jede JavaScript-API von Workers Rust-typische Bindings
  • Für Python Workers ist dieselbe Richtung geplant, beginnend mit Bindings für Workers AI und Vectorize
  • Während Rusts workers-rs externe Abhängigkeiten nutzt und aktualisiert werden muss, sollen die APIs von Python Workers direkt in die Workers-Runtime integriert werden
  • Nach einem Update des compatibility date lassen sich die neuesten Python-typischen APIs nutzen
  • Auf Basis der JavaScript-API connect() von Workers könnten auch Teile der Raw-Socket-API aus der Python-Standardbibliothek bereitgestellt werden
  • Cloudflare hofft, den Aufbau standardisierter serverless APIs anzustoßen, die dieselben Funktionen wie JavaScript bieten und zugleich für Python-Entwickler leicht nutzbar sind

Ausblick

  • Um eine neue Programmiersprache richtig zu unterstützen, braucht es deutlich mehr Investitionen als nur „hello world“
  • Laut der Stack-Overflow-Umfrage 2023 ist Python nach JavaScript die am zweithäufigsten verwendete Sprache
  • Cloudflare will die Performance von Python Workers weiter verbessern und den Umfang der Unterstützung für Python-Pakete erweitern
  • Feedback-Kanäle sind der Python-Workers-Channel im Cloudflare Developers Discord und die workerd GitHub discussion

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-03
Meinungen auf Hacker News

  • Es ist erfreulich, dass Cloudflare sich stärker darauf konzentriert, Python per WebAssembly am Edge auszuführen.
    Aus der Perspektive von Wasmer, wo wir uns mit WebAssembly-basierter Python-Ausführung am Edge beschäftigt haben, lässt sich sagen: Cloudflare Workers aktiviert Python am Edge mit Pyodide, also Python, das mit Emscripten nach WebAssembly kompiliert wurde.
    Die Architektur bindet Pyodide in Workerd ein und versucht, die Startzeit über V8-Snapshots zu verkürzen; im besten Fall liegt ein Python-Cold-Start bei etwa 1 Sekunde.
    Allerdings ist der aktuelle Ansatz an die in Workerd eingebaute Python-/Pyodide-Version gebunden, und auch die Paketauflösung ist stark mit Workerd gekoppelt. Zur Laufzeit dürften daher wahrscheinlich nur vorab kompilierte native Pakete erlaubt sein. Beispielsweise könnte die Nutzung einer bestimmten numpy-Version schwierig sein.
    Da das Ganze architektonisch an die JS-/V8-Welt gebunden ist, scheint es mit der aktuellen Architektur schwer, Startzeiten unter 100 ms zu erreichen.
    Trotzdem ist dieses Release willkommen, und ich freue mich darauf, dass Leute großartige Apps damit bauen.
    https://pyodide.org/
    https://github.com/cloudflare/workerd/blob/main/docs/pyodide...
    https://github.com/cloudflare/workerd/pull/1875
    Edit: Entsprechend der Erklärung des Cloudflare-Teams wurde „Proof of Concept“ zu „Release“ geändert.

    • Bei der Zusammenfassung der Versionierungsweise scheint es ein Missverständnis zu geben. Pyodide-/Paketversionen werden über Compatibility Dates gesteuert, und in der Produktion können mehrere Versionen gleichzeitig unterstützt werden.
      Pakete wie langchain oder das erwähnte numpy sollen ziemlich häufig aktualisiert werden.
      Es wäre gut, genauer zu erklären, warum V8 als limitierender Faktor gesehen wird. V8 ist eine leistungsfähige WebAssembly-Runtime, und die meisten der geplanten Optimierungen hängen nicht stark von der darunterliegenden Engine ab.
      Außerdem ist das kein Proof of Concept, sondern eine Beta, die weiter verbessert werden und bis zur GA gehen soll.
    • Zur Einordnung: Wasmer bietet ein Edge-Produkt, das bei der Ausführung von Python auf Cloudflare Workers die genannten Nachteile nicht hat und sehr schnelle Cold-Starts bietet.
      https://wasmer.io/templates?language=python
    • Es hieß, „Startzeiten unter 100 ms werden mit der aktuellen Architektur schwierig“; ich frage mich, wer Python-Workloads betreibt, die Latenzen unter 100 ms benötigen.
    • Ich frage mich, ob diese Architektur uvloop unterstützt.

  • Cloudflare hat beim Hosting und bei Datenbanken viel Gutes zu bieten, aber als Developer Platform machen sie ihr Marketing offenbar nicht besonders gut, sodass Vercel und Netlify einen beträchtlichen Share of Mind erobert haben.
    Unabhängig davon frage ich mich, ob Cloudflare einen sprachunabhängigen Container-Hosting-Dienst wie Google Cloud Run anbietet.

    • Ich stimme zu, dass beim Marketing irgendetwas nicht stimmt. Anfangs haben mich Vercel und Netlify angezogen, aber nachdem ich beide länger genutzt hatte und mit keinem zufrieden war, habe ich Cloudflare ausprobiert und es am Ende schätzen gelernt.
      Preise und Produkte sind hervorragend.
    • Es ist nicht nur ein Marketingproblem. Anfangs war ich optimistisch gegenüber Cloudflares Produktpalette, hatte aber große Probleme mit der Kompatibilität zu Website-Generatoren wie Next.js und Astro.
      Manche Funktionen funktionierten gar nicht, andere wurden nur teilweise unterstützt.
      Wenn man wertvolle Entwicklungszeit in die Behebung solcher Probleme stecken muss, waren alternative Plattformen wie Vercel, Netlify oder Deno Deploy für die Anforderungen des Teams reibungsloser, und man konnte sich leichter auf Entwicklung statt auf Infrastrukturprobleme konzentrieren.
    • Vercel und Netlify scheinen nicht wirklich auf Entwickler abzuzielen. Als Entwickler ist die Nutzung von Vercel und Netlify im Grunde so, als würde man sich über den Tisch ziehen lassen.
      Bandbreitenkosten sind bei Vercel und Netlify 40- bis 50-mal höher als bei den meisten Cloud-Anbietern, während Bandbreite bei Cloudflare kaum Kosten verursacht.
      Auch Edge-Function-Aufrufe sind bei Vercel und Netlify 6-mal teurer als bei Cloudflare. Die Kosten für Compute-Zeit, die bei Cloudflare kostenlos ist, sind dabei noch nicht eingerechnet.
      Der fast einzige Grund, warum Vercel beliebt ist, ist, dass es der beste Ort zum Hosten von NextJS ist; deshalb machen sie es vielleicht schwierig, NextJS anderswo bereitzustellen.
    • Soweit ich weiß, war der Free Tier von Cloudflare bis vor Kurzem ziemlich eingeschränkt. D1, ihre SQLite-Implementierung, wurde gestern allgemein verfügbar, und Read Replicas wurden ebenfalls angekündigt.
    • Etwas wie Google Cloud Run gibt es nicht, aber es wäre wirklich schön, wenn es das gäbe.
      Ich nutze Workers seit etwa vier Jahren in Produktion und mag sie, aber die meisten Apps betreibe ich weiterhin in Containern.

  • Ich habe JS Workers auf einer Site eingesetzt, die vor Cloudflare hängt, und sie waren einfach zu nutzen und sehr schnell. Ich würde gern die gesamte Django-App hinter der Site samt D1-Datenbank dorthin umziehen.

    • Bei mir ist es ähnlich. Ich habe ein paar Mobile Apps, die Cloudflare Workers und KV/D1 nutzen, und das war sehr gut.
      Wegen des geringen Traffics bleibe ich im Free Tier, aber es ist so einfach zu bauen, dass ich auch bereit wäre, dafür zu zahlen.
    • Stimme zu, das sieht wirklich großartig aus. Derzeit gibt es keine Django-/DRF-Unterstützung, aber es heißt, dass die Zahl der Pakete künftig erhöht werden soll.
    • Ist es klug, die gesamte Django-App hinter der Site bis hin zu D1 umzuziehen? Ein einziger DDoS-Angriff könnte das Budget sprengen.

  • Ein Performance-Vergleich mit JS Workern wäre hilfreich. Interessant, aber da mehrere Schichten ineinandergreifen, wirkt es potenziell langsamer
    Ich erwarte keine gleichwertige Performance, aber es wäre gut, die groben Trade-offs zu kennen

    • Performance hat hier drei Aspekte: Cold-Start-Performance, Performance nach dem Cold Start, die Bridge-Kosten zwischen JS und WebAssembly sowie die Geschwindigkeit des Python-Interpreters, der in WebAssembly läuft
      Aktuell ist der Cold Start von Python langsamer als bei einem gleich großen JavaScript Worker. Ein einfacher in JavaScript geschriebener „Hello World“-Worker hat eine Cold-Start-Zeit von nahezu 0, während ein Python Worker unter 1 Sekunde liegt
      Das liegt daran, dass Pyodide bei einer eingehenden Anfrage on demand in den Worker geladen werden muss; im Blogpost wird beschrieben, wie man Pyodide vorab verfügbar macht, um das zu reduzieren
      Nachdem ein Python Worker den Cold Start hinter sich hat, rückt der Unterschied jedoch eher an den Rand und kann je nachdem, was während der Anfrage passiert, nur ein paar Millisekunden betragen
      Beim Überqueren der „Bridge“ zwischen JavaScript und WebAssembly, etwa bei Ein-/Ausgabe oder asynchronen Operationen, entstehen geringe Kosten. Man sollte dabei aber eher in Mikrosekunden als in Millisekunden denken; in der Regel ist das sehr wenig
      Wer performancekritische Worker schreibt, nutzt teilweise schon Rust: https://github.com/cloudflare/workers-rs Auch das hängt von der Bridge zwischen JavaScript und WebAssembly ab
      Der WebAssembly-basierte Python-Interpreter von Pyodide ist nicht so schnell wie die über Jahre aufgebauten Optimierungen, die JavaScript in V8 schnell machen. Dennoch steht Pyodide im Vergleich zur JS-Engine von V8 noch am Anfang, und es gibt Bereiche, in denen große Performancegewinne möglich scheinen. Wir möchten Performanceverbesserungen upstream einbringen, und es gibt auch hilfreiche WebAssembly-Vorschläge
    • Vom Gefühl her wirkt es sehr schnell

  • Ich frage mich, ob die Wahl von lzma zur Demonstration der Isolation Absicht war oder ob das wegen der Tech-News der letzten Woche nur Zufall war
    https://news.ycombinator.com/item?id=39865810

    • Es wurde nur aufgenommen, weil es in der Standardbibliothek enthalten ist. Das Timing ist reiner Zufall, aber es ist schön, dass Wasm Isolationsgarantien bietet :-)

  • Das dürfte ziemlich ein Game Changer dafür werden, AI-bezogene Workloads auf Cloudflare laufen zu lassen. Darauf habe ich schon ziemlich lange gewartet

  • Ich habe es heute ausprobiert, fand es gut und konnte sehr schnell bis zur Ausführung kommen
    Allerdings frage ich mich, wie man die lokale Entwicklungsumgebung dazu bringt, die in CFWs Python-Implementierung eingebauten Libraries zu verstehen
    Es gibt zum Beispiel die Library asgi, und ich möchte, dass der Linter sie nicht als unbekannt markiert. Diese Library existiert aber nur zur Laufzeit des on_fetch-Handlers und ist auf der lokalen Entwicklungsmaschine tatsächlich nicht vorhanden, daher habe ich keine Lösung gefunden

  • Ich habe mit CF Pages für statische Sites gute Ergebnisse erzielt, und die Cloudflare-Produkte, die Open-Source-LLMs als Service anbieten, finde ich ebenfalls interessant
    Der Hauptgrund, der mich davon abgehalten hat, mehr auf Cloudflare zu bauen, war die fehlende Python-Unterstützung, und ich freue mich darauf, dieses Feature auszuprobieren

    • Ich nutze ebenfalls CF Pages und einige Worker-Funktionen, und das Cloudflare-Ökosystem ist wirklich gut
      Es ist leicht, schnell etwas zum Laufen zu bringen, ohne sich groß um Infrastruktur kümmern zu müssen
      Die Ergänzung um Python ist sehr willkommen, und es wäre schön, wenn auch Go als First-Class-Support dazukäme

  • Ich frage mich, wie die Einschränkung, nur Pyodide-Pakete verwenden zu können, bei nicht trivialen Builds funktioniert
    Es gibt viel Code, der nicht reines Python ist, und um echte Produktions-Apps zu unterstützen, müsste vermutlich vieles manuell neu gebaut werden
    Cloudflares Einführung könnte helfen, mehr Pakete anzuziehen, und wenn hier die 80/20-Regel greift, könnte das durchaus gut genug sein

    • Ich denke, hier gibt es eindeutig eine 80/20-Regel. Die meisten Pakete sind nicht besonders schwer zu portieren, und die schwer zu bauenden verwenden meist Funktionen, für die es in einer WebAssembly-Runtime kein klares Gegenstück gibt, etwa Threads und Multiprocessing, Grafikkarten, Raw Sockets oder Green Threads
      Wie auch im Blogpost erwähnt, ist das größte Problem die Unterstützung für server- und requestbezogene Pakete. Sie wären in Cloudflare Workers eindeutig nützlich, sind aber schwer zu portieren, weil sie häufig Raw Sockets und irgendeine Form von Nebenläufigkeit verwenden

  • Ich fände es gut, wenn CloudFlare Workers mit WASM als First-Class-Target und einer allgemeinen API implementieren würde, die nicht an JS Workers gebunden ist
    Schon jetzt kann man WASM-Code deployen und damit praktisch jede Sprache verwenden, aber es ist nicht nativ, sondern läuft innerhalb eines JS-Kontexts
    Beim Deployment gibt es etwas Overhead und Unbeholfenheit
    Ich glaube, dass am Ende alle Services direkt in sicherheitsgehärtete WASM-Runtimes deployt werden, statt in Container. Ähnlich wie der Übergang von Images zu Containern
    Der Vorteil, aktuell etwas wie Rust auf der Cloudflare Edge zu verwenden, ist nicht groß. Ein erheblicher Teil des Performancevorteils wird durch Overhead und Startzeit wieder aufgehoben
    Beispiel: https://github.com/WasmEdge/WasmEdge