Asgi on K-Life Hack | Systems Architecture & DevOps

Technical Considerations on the Evolution of Python Web Interfaces from CGI to ASGI and Modern WAS Configurations

Wed, 03 Jun 2026 09:08:46 +0900

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

The web server receives an HTTP request.
The server forks a new OS process for each request, executing the Python interpreter and script.
The script writes the result to standard output (stdout), and the process terminates.
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.

Technical Considerations in FastAPI Architecture Design and Implementation

Thu, 28 May 2026 10:04:17 +0900

Technical Analysis of FastAPI Internal Architecture and Runtime Behavior

FastAPI is a modern, high-performance web framework for building APIs based on standard Python type hints. This article provides a technical analysis of FastAPI’s internal architecture, data validation mechanisms, and asynchronous processing behavior at runtime.

1. Architectural Components and Design Philosophy

FastAPI achieves its functionality by integrating two independent primary libraries.

Starlette: Manages the foundation of the web ecosystem, including routing, middleware, and compliance with the ASGI specification.
Pydantic: Handles data validation, serialization, and OpenAPI schema generation.

Runtime Control via Type Hints

The most significant feature of FastAPI is its utilization of Python type hints not just as static analysis tools, but as runtime logic. The framework references type hints to automate the following processes:

Data Extraction: Determines where to retrieve values from (Path, Query, Body, or Header).
Validation: Applies strict verification rules based on the defined types.
Data Conversion: Automatically converts strings from URLs into types like int, float, or complex Pydantic models.
Documentation Generation: Reflects accurate data types and constraints in the OpenAPI schema.

For example, if a parameter is declared as an int and conversion fails, FastAPI automatically returns a 422 Unprocessable Entity. This eliminates the need for developers to manually write validation logic.

2. Execution Environment and Lifecycle Management

FastAPI provides a CLI to control different behaviors between development and production environments.

Differences in Execution Modes

Development Mode (fastapi dev): Auto-reload is enabled, and it binds to 127.0.0.1 by default for security reasons.
Production Mode (fastapi run): Auto-reload is disabled for stability, and it binds to 0.0.0.0 assuming containerization.

Considerations in Multi-worker Environments

⚠️ When starting multiple worker processes using the –workers option, each worker has an independent memory space. Therefore, in-memory global variables (such as lists or counters) are not shared between workers. If state management is required, a design utilizing an external store like Redis or a database is mandatory.

3. Parameter Handling and the Annotated Pattern

In FastAPI, it is recommended to use typing.Annotated to separate and integrate type information and metadata.

from typing import Annotated
from fastapi import FastAPI, Query

app = FastAPI()

@app.get("/items/")
async def read_items(
 q: Annotated[str | None, Query(max_length=50)] = None,
 size: Annotated[int, Query(ge=1)] = 10
):
 return {"q": q, "size": size}

💡 By using Annotated, you can maintain compatibility with standard Python tools while adding framework-specific constraints such as ge=1 (greater than or equal to 1) or max_length.

4. Data Modeling with Pydantic

Pydantic models are used for processing request bodies. This allows complex JSON structures to be handled safely as Python objects.

from pydantic import BaseModel, ConfigDict

class ItemModel(BaseModel):
 id: int
 name: str
 description: str | None = None

model_config = ConfigDict(from_attributes=True)

🛠️ When integrating with ORMs (such as SQLAlchemy), setting model_config = ConfigDict(from_attributes=True) allows data to be read from object attributes in addition to dictionary formats.

5. Asynchronous Execution Model: Distinguishing between async def and def

FastAPI switches the execution thread based on how the function is defined. Understanding this behavior is critical for performance optimization.

async def: Executed directly on the event loop. Only non-blocking code (processes involving await) should be written within the function.
def: Executed in an external thread pool. This mechanism prevents the event loop from being blocked when synchronous blocking processes (such as time.sleep() or synchronous DB drivers) are included.

⚠️ Warning: Calling a blocking function like time.sleep() within an async def will stop the entire event loop, preventing the server from processing other requests. If blocking processes are necessary, use a standard def or consider await asyncio.sleep().

6. Dependency Injection

FastAPI’s DI system is designed to modularize authentication, database session management, and common parameter processing.

from typing import Generator
from fastapi import Depends

def get_db_session() -&gt; Generator:
 db = SessionLocal()
 try:
 yield db
 finally:
 db.close()

💡 In dependencies using yield, the code up to the yield is executed before request processing, and the finally block is executed after the response is sent, ensuring reliable resource cleanup.

7. Middleware and CORS Configuration

Middleware, which intercepts all requests and responses, plays a vital role in security settings. In particular, CORS configuration to allow access from different domains is essential for integration with frontends.

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()

origins = [
 "http://localhost:3000",
]

app.add_middleware(
 CORSMiddleware,
 allow_origins=origins,
 allow_credentials=True,
 allow_methods=["*"],
 allow_headers=["*"],
)

8. Application Structuring and Life Events

In large-scale applications, APIRouter is used to split routes and improve maintainability. Additionally, using the lifespan context manager allows for defining logic that runs only once at application startup and shutdown (such as loading machine learning models or establishing DB connections).

from contextlib import asynccontextmanager
from fastapi import FastAPI, APIRouter

@asynccontextmanager
async def lifespan(app: FastAPI):
 # Startup logic (e.g., connection pool initialization)
 yield
 # Shutdown logic (e.g., connection pool cleanup)

app = FastAPI(lifespan=lifespan)
router = APIRouter()

@router.get("/users")
async def get_users():
 return [{"username": "user1"}]

app.include_router(router)

Summary

FastAPI integrates a robust ASGI foundation via Starlette with strict data validation via Pydantic through the intuitive interface of Python type hints. By understanding the proper use of async def versus def, metadata management with Annotated, and resource control via lifespan, it is possible to build scalable and highly maintainable API architectures.