Rozdział 22 · Tworzenie stron internetowych z Python

WSGI i ASGI: komunikacji między aplikacją webową a serwerem

Ramy opisują, co zrobić z żądaniem. WSGI i ASGI to umowa dotycząca sposobu, w jaki żądanie do niego dotrze.

Rozdział 22.18 wspomniała WSGI i ASGI jako różnicę techniczną między ramami. Przyjrzyjmy się temu Co oznaczają na poziomie idei, bez szczegółów wdrożenia.

WSGI (Web Server Gateway Interface) oraz ASGI (Asynchronous Server Gateway Interface) — standardowe interfejsy opisujące, w jaki sposób serwer aplikacji przekazuje zapytanie HTTP do aplikacji Python i otrzymuje od niej odpowiedź. W normalnym wdrożeniu połączenia sieciowe obsługuje serwer aplikacji lub inna infrastruktura serwerowa, a nie sam framework (Flask, Django, FastAPI) bezpośrednio — WSGI/ASGI to właśnie ogólne porozumienie między nimi.

Flask i async to nie to samo co framework ASGI-framework

Flask wie, jak przywołać async def-obsługujące, ale samo aplikacja w tym czasie pozostaje WSGI-aplikacją według architektury: do wykonania takiego handlera Flask uruchamia pętlę zdarzeń i wykonuje w niej korutynę, zajmując przy tym jeden handler żądania na cały czas jej działania. Jest to wygodne, gdy konkretny handler musi czekać na powolną operację wejścia-wyjścia, ale nie przekształca Flask w pełnoprawny ASGI-framework jak FastAPI — jeśli aplikacji zasadniczo zależy na asynchronicznym modelu na wszystkich poziomach, ASGI-framework będzie lepszy.

Framework i serwer aplikacji to różne rzeczy

Flask lub FastAPI opisuje co robić z zapytaniem. Oddzielny program — serwer aplikacji jest odpowiedzialny za faktyczne zaakceptowanie połączenia przez nasiewanie sieci i przekazywanie żądania do frameworka przez protokół WSGI lub ASGI:

Do tego rozróżnienia wrócimy w Sekcji 22.34 – Serwer deweloperski wbudowany w Flask, oraz Serwer aplikacji desktopowych wykonuje to samo zadanie na różne sposoby.