ASGI (de l'anglès Asynchronous Server Gateway Interface) és una especificació d'interfície entre servidors web, frameworks i aplicacions Python compatibles amb programació asíncrona. Va ser dissenyada com a successora conceptual de WSGI, amb l'objectiu d'oferir una interfície comuna per a aplicacions web que utilitzen operacions asíncrones, connexions de llarga durada o protocols que no encaixen bé en el model clàssic de petició i resposta.

ASGI permet separar el servidor que rep les connexions de xarxa de l'aplicació Python que processa les peticions. D'aquesta manera, un mateix framework pot executar-se sobre diferents servidors compatibles amb ASGI, i un mateix servidor pot allotjar aplicacions creades amb frameworks diversos. La seva adopció està associada al creixement de les aplicacions web asíncrones en Python i a l'ús de biblioteques basades en asyncio.

Relació amb WSGI WSGI va proporcionar durant anys una interfície estàndard entre servidors web i aplicacions Python síncrones. Tanmateix, el seu model es basa principalment en una funció que rep una petició HTTP i retorna una resposta, fet que resulta limitat per a càrregues de treball asíncrones o per a protocols de connexió persistent, com ara WebSocket.

ASGI manté la idea d'una interfície comuna entre servidor i aplicació, però adapta el model a l'execució asíncrona. La documentació oficial el descriu com un successor espiritual de WSGI, pensat per donar suport tant a aplicacions asíncrones com a aplicacions síncrones, i també per facilitar la compatibilitat amb diferents servidors i frameworks.

Funcionament general Una aplicació ASGI és habitualment una funció o objecte cridable asíncron que rep tres paràmetres: scope, receive i send. El paràmetre scope és un diccionari que conté informació sobre la connexió, com el tipus de protocol, la ruta sol·licitada o les capçaleres HTTP. Els paràmetres receive i send són funcions asíncrones que permeten rebre i enviar missatges entre el servidor i l'aplicació.

Aquest model basat en missatges permet representar diferents protocols amb una estructura comuna. En una petició HTTP, per exemple, l'aplicació pot rebre informació de la petició i enviar un missatge d'inici de resposta seguit d'un o més missatges amb el cos de la resposta. En una connexió WebSocket, en canvi, la mateixa interfície pot mantenir l'intercanvi de missatges durant més temps.

Arquitectura En una arquitectura ASGI hi intervenen habitualment tres elements: el servidor, el framework i l'aplicació. El servidor ASGI s'encarrega d'acceptar les connexions de xarxa i convertir els esdeveniments del protocol en missatges ASGI. El framework interpreta aquests missatges i ofereix abstraccions més còmodes, com rutes, peticions, respostes o middleware. L'aplicació conté la lògica pròpia del servei web.

Aquesta separació facilita que les aplicacions no depenguin directament d'un servidor concret. Per exemple, una mateixa aplicació compatible amb ASGI pot executar-se amb servidors diferents sempre que respectin l'especificació. També permet que alguns components intermedis, com el middleware, es puguin construir seguint la mateixa interfície i reutilitzar-se en diversos frameworks.

Protocols compatibles L'especificació principal d'ASGI està pensada per donar suport a diversos estils de protocol, incloent-hi HTTP, HTTP/2 i WebSocket. Aquesta flexibilitat és una de les diferències principals respecte del model WSGI tradicional, que està orientat sobretot al cicle petició-resposta d'HTTP.

Gràcies a aquest disseny, ASGI és adequat per a aplicacions que necessiten comunicació bidireccional, notificacions en temps real o connexions persistents. També es pot utilitzar en serveis web convencionals quan es vol aprofitar l'execució asíncrona per gestionar moltes operacions d'entrada i sortida sense bloquejar el fil principal de l'aplicació.

Cicle de vida i middleware ASGI també defineix mecanismes per representar esdeveniments que no corresponen només a una petició HTTP individual. Un exemple és el protocol de cicle de vida, que permet comunicar a una aplicació l'inici o l'aturada del servidor. Això és útil per preparar recursos compartits, com connexions a bases de dades o clients HTTP, i tancar-los correctament quan l'aplicació finalitza.

El middleware ASGI és un component que se situa entre el servidor i l'aplicació o entre dues aplicacions ASGI. Pot inspeccionar o modificar els missatges que passen per la interfície, per exemple per afegir capçaleres, gestionar sessions, aplicar polítiques de seguretat o registrar informació de les peticions. Com que utilitza la mateixa interfície bàsica, pot oferir interoperabilitat entre diferents parts de l'ecosistema.

Consideracions L'ús d'ASGI no fa que una aplicació sigui automàticament més ràpida. El guany principal apareix quan el programa fa moltes operacions d'entrada i sortida que poden esperar-se de manera concurrent, com consultes a serveis externs, accés a bases de dades o comunicació amb clients. Si una aplicació executa codi intensiu de CPU dins del bucle d'esdeveniments, pot continuar bloquejant altres tasques. Per això, ASGI s'acostuma a combinar amb biblioteques asíncrones i amb una gestió adequada de les operacions bloquejants.

Implementacions i frameworks Diversos servidors i frameworks de Python implementen o utilitzen ASGI. Django dona suport al desplegament amb ASGI i el presenta com l'estàndard emergent per a servidors i aplicacions web asíncrones en Python. Starlette es defineix com un framework i conjunt d'eines ASGI lleuger per construir serveis web asíncrons en Python.

Entre els servidors compatibles amb ASGI hi ha Uvicorn i Daphne. Uvicorn es presenta com una implementació de servidor ASGI per a Python i indica que l'especificació ASGI proporciona una interfície comuna per a frameworks asíncrons.

Vegeu també WSGI Django (marc web) FastAPI Python WebSocket Programació asíncrona

Referències

Categoria:Python Categoria:Programació Categoria:Internet