Service worker przechwytuje żądania HTTP i obsługuje je w aplikacji Python ASGI działającej bezpośrednio w przeglądarce

Simon Willison opisał eksperyment badawczy, w którym aplikacje Python ASGI działają bezpośrednio w przeglądarce dzięki Pyodide i service workerowi. Kontynuuje tym prace nad Datasette Lite, wersją Datasette działającą w WebAssembly bez klasycznego serwera, ale tym razem przeszedł z Web Workers na service worker, który rozwiązuje wcześniejszy problem: skrypty w elementach script nie były w ogóle wykonywane w wariancie z Web Worker.

Service worker przechwytuje żądanie i kieruje je do aplikacji Python ASGI bez backendu

Mechanizm jest technicznie przejrzysty: runtime Pythona działa w przeglądarce dzięki Pyodide, podczas gdy service worker przechwytuje żądania tego samego origin pod /app/ i kieruje je do aplikacji ASGI. Przeglądarka staje się małym lokalnym środowiskiem, które może obsługiwać ruch podobny do HTTP bez zdalnego backendu.

Willison zweryfikował podejście na dwóch konkretnych przypadkach: demo FastAPI i kompletnym Datasette 1.0a31. Service worker rozwiązuje kluczowy problem pierwotnej implementacji Web Worker, w której skrypty w elementach script nie były wykonywane, co psuło pluginy.

Dla narzędzi danych i dokumentacji to interesujący model dystrybucji

Dla narzędzi developerskich to atrakcyjne podejście. Dokumentacja może zawierać żywą aplikację, demo może działać bez konta i deployu, materiały szkoleniowe mogą działać offline, a bardziej wrażliwe dane nie muszą opuszczać przeglądarki.

Ważne jest też ASGI, bo to znany interfejs w świecie webowego Pythona. Jeśli to podejście się ustabilizuje, eksperymenty nie będą musiały być przepisywane do JavaScriptu tylko po to, by dało się je udostępnić jako strony. Datasette Lite jako długotrwały projekt pokazuje, że ta droga jest wykonalna, a nie tylko konceptualne demo.

Przeglądarka ma limity, które uniemożliwiają zastąpienie produkcyjnego backendu

Przeglądarka ma limity wydajności, pamięci, trwałości danych, bezpieczeństwa i integracji. Willison sam przyznaje, że wciąż w pełni poznaje, jak service worker zachowuje się w tym ustawieniu. Service worker nie zamienia też lokalnego demo w solidną usługę multi-user.

Główna wartość leży w dystrybucji: jeśli małą aplikację Python można dostarczyć jako stronę, spada tarcie między pomysłem, demem i walidacją.

Tooling i ekosystem zdecydują, czy to zostanie eksperymentem, czy stanie się wzorcem

Kluczowe będą cache, zarządzanie pakietami, ciężar pobierania i dostęp do lokalnych danych. Najważniejszy będzie tooling, który zamieni zwykłą aplikację ASGI w browser-ready demo bez ręcznej magii.

Najbardziej obiecujące obszary to narzędzia danych, dokumentacja i edukacja. Tam lokalny Python w przeglądarce może zdjąć najwięcej operacyjnego ciężaru i zmniejszyć zależność od infrastruktury serwerowej.

Werdykt Lilith

To podejście nie zastępuje serwera. Zmniejsza tarcie między pomysłem a pokazem: aplikacja Python jako strona, bez deployu, bez konta, bez infrastruktury serwerowej.