Web application interface standards in Python have evolved from the early CGI to WSGI, and now to modern ASGI. This article provides a technical analysis of the operating principles, performance characteristics of each protocol, and the role of the WAS (Web Application Server) in modern infrastructure.

1. Structure and Limitations of CGI (Common Gateway Interface)

CGI is the earliest standard protocol for web servers to interact with external programs. Its core lies in the “process-per-request” model.

💡 Operating Logic

1. The web server receives an HTTP request.
2. The server forks a new OS process for each request, executing the Python interpreter and script.
3. The script writes the result to standard output (stdout), and the process terminates.
4. The server returns that output to the client as an HTTP response.

⚠️ Technical Challenges

Because this model loads the interpreter and initializes the environment for every request, the overhead is extremely high, making it unsuitable for operation in high-traffic environments. While safety is ensured through process isolation, it is rarely adopted in modern systems due to resource efficiency concerns.

2. Optimization via WSGI (Web Server Gateway Interface)

WSGI was formulated to resolve the overhead of CGI. WSGI provides a standard interface that keeps the Python application in memory as a persistent process to handle requests.

🛠️ Key Implementation Points

In WSGI, the application is defined as a “callable object (Callable)”. Once the server loads this object, it can call it repeatedly without restarting the process.

def application(environ, start_response):
    status = '200 OK'
    headers = [('Content-Type', 'text/plain; charset=utf-8')]
    start_response(status, headers)
    return [b"Hello, WSGI World"]

In current production environments, a configuration placing Nginx as a reverse proxy and Gunicorn as the WSGI server (WAS) is common.

3. Transition to ASGI (Asynchronous Server Gateway Interface)

Since WSGI is designed assuming a synchronous request-response cycle, it has limitations in handling modern asynchronous communications such as WebSockets, Long Polling, and HTTP2. ASGI emerged to resolve this.

💡 Characteristics of ASGI

While inheriting the spirit of WSGI, ASGI natively supports Python’s async/await syntax. This makes it possible to efficiently manage thousands of concurrent connections in a single process using asynchronous I/O.

async def application(scope, receive, send):
    if scope['type'] == 'http':
        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                (b'content-type', b'text/plain'),
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': b'Hello, ASGI World',
        })

4. Definition of the WAS (Web Application Server) Layer

In system architecture, it is important to clearly define the division of roles between the web server (Nginx, Apache) and the WAS (Gunicorn, Uvicorn).

• Web Server: Responsible for serving static files, SSL/TLS termination, reverse proxying, and load balancing.
• WAS: Responsible for executing business logic, database operations, and generating dynamic content. In the Python ecosystem, WSGI/ASGI servers correspond to this WAS layer.

5. Architectural Comparison of Frameworks

Django

A full-stack framework designed in the WSGI era, encompassing features such as an ORM and an admin panel. Since Django 3.0, native support for ASGI has been added, allowing both synchronous and asynchronous views to coexist.

FastAPI

A modern framework built from the ground up assuming ASGI. It maximizes the use of asynchronous I/O, delivering high throughput particularly in I/O-bound tasks such as inference endpoints for AI/machine learning models. It is also optimized for development efficiency, featuring automatic document generation leveraging type hints.

Findings

The choice of Python web interface depends on the communication characteristics of the application. For synchronous systems centered on simple CRUD operations, WSGI (Gunicorn + Django/Flask) can ensure sufficient stability. However, when building real-time communication or highly concurrent API servers, transitioning to ASGI (Uvicorn + FastAPI/Django ASGI) is indispensable. In infrastructure design, it is necessary to select the appropriate WAS configuration, considering the impact of these interface standards on resource consumption and latency.