Home > Article > Backend Development > ASGI explained: The future of Python web development
Translator|Li Rui
Reviewer|Sun Shujuan
Python web applications have long followed the Web Server Gateway Interface (WSGI) standard, which The standard describes how they communicate with web servers. WSGI, originally introduced in 2003 and updated in 2010, relies only on easy-to-implement features that are natively available in Python 2.2. As a result, WSGI was quickly integrated into all major Python web frameworks and became the cornerstone of Python web development.
Fast forward to 2022. Python2 has been deprecated and Python now has native syntax for handling asynchronous operations such as network calls. WSGI and other standards that assume synchronous behavior by default fail to take advantage of the performance and efficiency gains of asynchronous. This in turn means that WSGI cannot handle high-level protocols like WebSocket efficiently.
Enter ASGI, which is the Asynchronous Server Gateway Interface. Similar to WSGI, ASGI describes a common interface between Python web applications and web servers. Unlike WSGI, ASGI allows multiple asynchronous events per application. Additionally, ASGI supports both synchronous and asynchronous applications. Developers can migrate legacy synchronous WSGI web applications to ASGI or build new asynchronous web applications using ASGI.
The working principle of WSGI is to expose Python functions to the web server, usually named as an application or app. This function takes two parameters:
The data returned by the function constitutes the response body.
A simple application function might look like this:
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return [b'Greetings universe']
If you are using a WSGI-compatible web framework (such as Flask ), then the framework itself will provide an application functionality and all its components will be automatically connected.
WSGI has two disadvantages: First, WSGI only handles one request and response at a time and assumes that the response will be returned immediately. There is no way to handle long-held connections, such as WebSocket or long-polling HTTP connections.
Secondly, WSGI is only synchronous. Even with multi-threaded connection pooling, each connection blocks until it returns a response. Many WSGI setups are able to handle thread pools and process pools, but these are limited by the synchronization of the WSGI interface itself.
ASGI is similar in appearance to WSGI. Like WSGI, developers can define an application function object, but it is an asynchronous function with three parameters instead of two:
scope: Contains information about the current request A dictionary of information, similar to environ in WSGI, but the details of the naming convention are slightly different.
send: An asynchronous callable function that allows the application to send messages back to the client.
receive: Asynchronous callable function that allows the application to receive messages from the client.
A simple ASGI application function looks like this:
async def application(scope, receive, send):
await send({
'type': 'http.response.start',
'status': 200,
'headers': [
[b'content-type', b'text/plain'],
],
})
await send({
'type': 'http.response.body',
'body': b'Hello, world!',
})
Like the WSGI Web framework, the ASGI Web framework will generate its own application () function and connect them as needed.
The most obvious difference from ASGI is the use of asynchronous metaphors throughout the function. The function itself is asynchronous, where the HTTP headers and response body are sent via two separate await send() commands. This way, the functions themselves and their send commands don't block anything; they can be intertwined with the application's calls and sent from many other connections simultaneously.
receive is not used in this example, but it is also an asynchronous function. It allows receiving the request body without blocking other operations. Requests and responses can be passed incrementally to or from the server in this manner - something that cannot be done well, or perhaps at all, with WSGI.
When using ASGI, you need to use as many asynchronous functions and async-friendly libraries as possible. It pays to get into the habit of using async, as the problems with using synchronous-only code can be serious. Any long call to a synchronous function will block the entire call chain, making the benefits of using async almost gone.
If you encounter problems when using long-running synchronous calls, you need to use asyncio.run_in_executor to outsource the call to a thread pool or process pool. Thread pools should be used whenever waiting for external events or non-CPU-intensive tasks. The process pool should be used for CPU-intensive local tasks.
For example, if there is a route in a web application that can call a remote website, then threads should be used. Or better yet, use the aiohttp library that makes asynchronous HTTP requests. If you want to call the Pillow image library to resize the image, you should probably use run_in_executor with a process pool. Although there is some slight overhead in transferring data back and forth between processes, using run_in_executor does not block other events.
By implementing the application() object, ASGI Web applications can be written manually. But in most cases, it's simpler to use an asynchronous native, ASGI-centric Python web framework. Here are some common ASGI-compatible web frameworks:
Starlette and FastAPI: These emerging frameworks (FastAPI is built on top of Starlette) are async-first, so they all support ASGI No wonder. If you are developing web applications from scratch, then they are the most modern and cutting-edge web frameworks for Python.
Quart: While the major Python web framework Flask does support ASGI, Flask is not designed to leverage async metaphors from the inside out. Quart from GitLab uses Flask's syntax and metaphors but allows for asynchronous route handlers.
Django 3.0 and above: Starting from Django 3.0, the prestigious Django web framework supports ASGI. Support for asynchronous code in Django applications was added in Django 3.1, rather than just being able to mount Django on ASGI handlers. For a framework not known for execution speed, the presence of async brings better performance to those who choose to take advantage of it.
Original link: https://www.infoworld.com/article/3658336/asgi-explained-the-future-of-python-Web-development.html
The above is the detailed content of ASGI explained: The future of Python web development. For more information, please follow other related articles on the PHP Chinese website!