mirror of
https://github.com/Rainyy21/framework_note.git
synced 2026-10-10 23:40:30 -04:00
vault backup: 2026-06-01 23:17:01
This commit is contained in:
Rainyy21
+1
-1
@@ -13,7 +13,7 @@ All notes under `note/LLM/`, grouped by subfolder.
|
||||
|
||||
```dataview
|
||||
LIST rows.file.link
|
||||
FROM "note/LLM"
|
||||
FROM "saveToGit/note/LLM"
|
||||
WHERE file.name != "index"
|
||||
GROUP BY file.folder
|
||||
SORT file.folder ASC
|
||||
|
||||
@@ -13,7 +13,7 @@ All notes under `note/python/`, grouped by subfolder.
|
||||
|
||||
```dataview
|
||||
LIST rows.file.link
|
||||
FROM "note"
|
||||
FROM "saveToGit/note"
|
||||
WHERE file.name != "index"
|
||||
GROUP BY file.folder
|
||||
SORT file.folder ASC
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
tags:
|
||||
- python
|
||||
- web-development
|
||||
- flask
|
||||
- fastapi
|
||||
- asgi
|
||||
- wsgi
|
||||
created: 2026-06-01
|
||||
category: programming
|
||||
---
|
||||
|
||||
# Flask vs. FastAPI: Choosing the Right Framework in 2026
|
||||
|
||||
Both **Flask** and **FastAPI** are prominent Python web frameworks, but they serve different needs and architectural goals. This guide breaks down their core differences to help you choose the right tool for your project.
|
||||
|
||||
## 1. Architectural Foundation
|
||||
The most fundamental difference lies in how these frameworks handle communication between the server and the application.
|
||||
|
||||
* **Flask (WSGI-Hybrid):** Originally built on the **WSGI (Web Server Gateway Interface)** specification. While Flask 3.x+ has introduced "Sans-IO" patterns and supports `async` views, it remains primarily a synchronous framework. Concurrency is typically handled via thread pools.
|
||||
* **FastAPI (ASGI-Native):** Built from the ground up on the **ASGI (Asynchronous Server Gateway Interface)** specification, using **Starlette** as its core. It is designed for native `async/await` support, allowing it to handle thousands of concurrent connections (like streaming AI responses) efficiently without blocking.
|
||||
|
||||
## 2. Performance and Data Validation
|
||||
FastAPI is significantly faster in most benchmarks due to its underlying technologies.
|
||||
|
||||
| Feature | Flask (2026) | FastAPI (2026) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Server Standard** | WSGI (Gunicorn/uWSGI) | ASGI (Uvicorn/Hypercorn) |
|
||||
| **Speed** | Fast (Synchronous/Threaded) | Blazing Fast (Async/Event-loop) |
|
||||
| **Data Validation** | Manual or via Extensions | Native via **Pydantic V2+** (Rust-based) |
|
||||
| **Type Hints** | Optional / Not required | Central / Mandatory for features |
|
||||
| **JSON Engine** | Customizable (default: standard) | High-speed (native `orjson`/`msgspec`) |
|
||||
|
||||
## 3. Key Features Comparison
|
||||
|
||||
### **FastAPI Highlights**
|
||||
* **Automatic Documentation:** Generates interactive API documentation (Swagger UI and ReDoc) automatically from your code and type hints.
|
||||
* **AI Integration:** In 2026, FastAPI features native "AI Agent Skills" manifests, making it the preferred choice for building APIs that interact with LLMs and AI agents.
|
||||
* **Type Safety:** Uses Python type hints for data validation, serialization, and documentation. If your code compiles/types-checks, your API is largely valid.
|
||||
* **Performance:** The Rust-powered Pydantic core makes data parsing and validation nearly as fast as compiled languages.
|
||||
|
||||
### **Flask Highlights**
|
||||
* **Simplicity and Flexibility:** A "micro" framework that doesn't make decisions for you. You only add what you need.
|
||||
* **Mature Ecosystem:** With over 15 years of history, Flask has a stable extension for almost everything (Flask-SQLAlchemy, Flask-Login, etc.).
|
||||
* **Low Learning Curve:** For developers familiar with traditional synchronous programming, Flask is often easier to pick up quickly.
|
||||
* **Stability:** Excellent for stable, internal tools or CRUD applications where high-concurrency async performance isn't a requirement.
|
||||
|
||||
## 4. Which One to Choose?
|
||||
|
||||
| Use Case | Recommended | Reason |
|
||||
| :--- | :--- | :--- |
|
||||
| **AI/ML & LLM APIs** | **FastAPI** | Native async for streaming tokens and I/O concurrency. |
|
||||
| **Real-time Apps** | **FastAPI** | Native WebSockets and SSE support via ASGI. |
|
||||
| **High Performance** | **FastAPI** | Faster serialization and non-blocking I/O. |
|
||||
| **Rapid Prototyping** | **Flask** | Less boilerplate and lower initial complexity. |
|
||||
| **Legacy Integration** | **Flask** | Better compatibility with older WSGI-based systems. |
|
||||
| **Simple CRUD** | **Flask** | Straightforward and battle-tested for standard web apps. |
|
||||
|
||||
## 5. Summary
|
||||
In 2026, **FastAPI** has become the standard for modern, high-concurrency, and AI-driven applications. However, **Flask** remains a powerful and relevant choice for developers who value simplicity, stability, and a massive ecosystem of tried-and-tested extensions.
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
aliases:
|
||||
up: "[[00_devop_note]]"
|
||||
tags:
|
||||
- devop
|
||||
---
|
||||
|
||||
# Uvicorn and Gunicorn
|
||||
|
||||
Both are Python application servers — they run your Python web app and hand requests back and forth with a web server like Nginx. But they solve **different problems**, and you'll often see them used **together**.
|
||||
|
||||
The key split: **Gunicorn is WSGI** (synchronous), **Uvicorn is ASGI** (asynchronous).
|
||||
|
||||
## Quick refresher: WSGI vs ASGI
|
||||
|
||||
| | WSGI | ASGI |
|
||||
|---|---|---|
|
||||
| Spec | PEP 3333 | "Asynchronous Server Gateway Interface" |
|
||||
| Model | Sync, one request per worker at a time | Async, many concurrent requests per worker |
|
||||
| Frameworks | Django (classic), Flask | FastAPI, Starlette, Django (async views), Sanic |
|
||||
| Supports WebSockets? | No | Yes |
|
||||
| Supports HTTP/2, SSE? | No | Yes |
|
||||
|
||||
If your app uses `async def` view functions or WebSockets, you need ASGI.
|
||||
If it's a traditional Django/Flask app with `def` views, WSGI is fine.
|
||||
|
||||
---
|
||||
|
||||
## Gunicorn ("Green Unicorn")
|
||||
|
||||
A **WSGI** server. Mature, simple, battle-tested. The de facto default for Django/Flask in production.
|
||||
|
||||
### Why people pick it
|
||||
|
||||
- **Simple config** — most options are sensible by default
|
||||
- **Pre-fork worker model** — master process forks N workers; each worker handles one request at a time
|
||||
- **Stable** — has been the standard for years
|
||||
- **Good signal handling** — graceful reloads, zero-downtime restarts
|
||||
|
||||
### Minimal usage
|
||||
|
||||
```bash
|
||||
gunicorn myproject.wsgi:application --workers 4 --bind 0.0.0.0:8000
|
||||
```
|
||||
|
||||
Or with a config file `gunicorn.conf.py`:
|
||||
|
||||
```python
|
||||
bind = "unix:/tmp/myproject.sock"
|
||||
workers = 4
|
||||
worker_class = "sync" # default
|
||||
timeout = 30
|
||||
accesslog = "-"
|
||||
errorlog = "-"
|
||||
```
|
||||
|
||||
### Worker classes
|
||||
|
||||
Gunicorn lets you swap the worker type:
|
||||
|
||||
- `sync` — default, one request at a time per worker
|
||||
- `gthread` — threaded workers (good for I/O-bound apps)
|
||||
- `gevent` / `eventlet` — async via greenlets (legacy)
|
||||
- `uvicorn.workers.UvicornWorker` — **this is the bridge to ASGI** (see below)
|
||||
|
||||
### How many workers?
|
||||
|
||||
Rule of thumb: `(2 × CPU cores) + 1`. So a 4-core box → 9 workers.
|
||||
|
||||
---
|
||||
|
||||
## Uvicorn
|
||||
|
||||
An **ASGI** server built on `uvloop` and `httptools` — both written in C, which makes it very fast. It's the standard server for FastAPI and modern async Python web apps.
|
||||
|
||||
### Why people pick it
|
||||
|
||||
- **Async-native** — handles thousands of concurrent connections per worker
|
||||
- **WebSockets + HTTP/2 support**
|
||||
- **Very fast** — uvloop is a drop-in faster replacement for asyncio's event loop
|
||||
- **Lightweight** — small dependency surface
|
||||
|
||||
### Minimal usage
|
||||
|
||||
```bash
|
||||
uvicorn myproject.main:app --host 0.0.0.0 --port 8000
|
||||
```
|
||||
|
||||
For development with auto-reload:
|
||||
|
||||
```bash
|
||||
uvicorn myproject.main:app --reload
|
||||
```
|
||||
|
||||
### Where it falls short alone
|
||||
|
||||
Uvicorn by itself is **single-process**. To use multiple CPU cores in production, you need to either:
|
||||
|
||||
1. Run multiple Uvicorn instances behind a load balancer, OR
|
||||
2. Run Uvicorn **inside Gunicorn** as worker processes (the common pattern)
|
||||
|
||||
---
|
||||
|
||||
## The common production combo: Gunicorn + Uvicorn
|
||||
|
||||
This is the standard FastAPI production setup:
|
||||
|
||||
```bash
|
||||
gunicorn myproject.main:app \
|
||||
--workers 4 \
|
||||
--worker-class uvicorn.workers.UvicornWorker \
|
||||
--bind 0.0.0.0:8000
|
||||
```
|
||||
|
||||
What's happening:
|
||||
|
||||
- **Gunicorn** is the process manager — forks workers, handles signals, restarts dead workers, manages graceful shutdowns
|
||||
- **Uvicorn** runs *inside* each Gunicorn worker — provides the ASGI event loop that runs your async code
|
||||
|
||||
You get the best of both: Gunicorn's robust process management + Uvicorn's async performance.
|
||||
|
||||
### Visual
|
||||
|
||||
```
|
||||
┌─ Uvicorn worker (async loop) ─ FastAPI app
|
||||
│
|
||||
Nginx → Gunicorn ├─ Uvicorn worker (async loop) ─ FastAPI app
|
||||
(master) │
|
||||
├─ Uvicorn worker (async loop) ─ FastAPI app
|
||||
│
|
||||
└─ Uvicorn worker (async loop) ─ FastAPI app
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Decision guide
|
||||
|
||||
| Your situation | Use |
|
||||
|---|---|
|
||||
| Django (sync), Flask | **Gunicorn** alone |
|
||||
| FastAPI, Starlette, async Django | **Gunicorn + UvicornWorker** |
|
||||
| Local dev, single FastAPI process | **Uvicorn** alone (`--reload`) |
|
||||
| WebSockets required | Must be ASGI → **Uvicorn** (alone or under Gunicorn) |
|
||||
| Legacy app, uWSGI already configured | [[uWSGI]] — no urgent need to migrate |
|
||||
|
||||
---
|
||||
|
||||
## Comparison with [[uWSGI]]
|
||||
|
||||
| | Gunicorn | Uvicorn | uWSGI |
|
||||
|---|---|---|---|
|
||||
| Protocol | WSGI | ASGI | WSGI (+ many others) |
|
||||
| Async support | No (sync workers) | Yes (native) | Limited |
|
||||
| Config complexity | Low | Low | **Very high** |
|
||||
| WebSockets | No | Yes | Partial |
|
||||
| Speed (raw) | Good | **Fastest** for async | Fast but heavy |
|
||||
| Maintained actively | Yes | Yes | Concerns |
|
||||
| Best for | Django/Flask | FastAPI | Legacy / specialized features |
|
||||
|
||||
---
|
||||
|
||||
## Common gotchas
|
||||
|
||||
1. **Don't run Uvicorn `--reload` in production** — it's a dev-only feature, has overhead and isn't safe.
|
||||
2. **Workers ≠ threads** — each Gunicorn worker is a separate Python process with its own memory. Database connections, in-memory caches, etc. are *not* shared between workers.
|
||||
3. **Timeouts matter** — Gunicorn's default `timeout=30s` will kill workers running long async tasks. Tune it for your workload.
|
||||
4. **Nginx is still recommended in front** — Uvicorn/Gunicorn don't do SSL termination, static files, or rate limiting as well as Nginx.
|
||||
5. **Logging** — by default both log to stdout/stderr; route to your log aggregator via container stdout (`-` in config).
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [[uWSGI]] — older alternative, mostly WSGI
|
||||
- [[Apache Tomcat]] — the Java equivalent (servlet container)
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
tags:
|
||||
- python
|
||||
- web-development
|
||||
- flask
|
||||
- wsgi
|
||||
created: 2026-06-01
|
||||
category: programming
|
||||
---
|
||||
|
||||
# WSGI vs. Flask: Understanding the Relationship
|
||||
|
||||
In the Python web ecosystem, **WSGI** and **Flask** operate at different layers of the stack. Here is a breakdown of their differences and how they work together.
|
||||
|
||||
## 1. What is WSGI?
|
||||
**WSGI (Web Server Gateway Interface)** is a **specification**, not a software or a framework. Defined in [PEP 3333](https://peps.python.org/pep-3333/), it describes a standard interface between web servers (like Nginx or Apache) and Python web applications or frameworks.
|
||||
|
||||
* **Role:** It acts as a bridge. It ensures that any WSGI-compliant server can run any WSGI-compliant application.
|
||||
* **Key Characteristics:**
|
||||
* Simple interface: A callable object (usually a function or class) that accepts two arguments (the environment dictionary and a `start_response` function).
|
||||
* Low-level: It doesn't handle routing, templating, or cookies directly; it just passes data back and forth.
|
||||
* **Examples of WSGI Servers:** Gunicorn, uWSGI, Waitress.
|
||||
|
||||
## 2. What is Flask?
|
||||
**Flask** is a **micro web framework** built on top of the WSGI specification. It provides the tools, libraries, and technologies to build a web application.
|
||||
|
||||
* **Role:** It simplifies development by providing high-level abstractions for common tasks.
|
||||
* **Key Characteristics:**
|
||||
* Built-in routing (mapping URLs to Python functions).
|
||||
* Template engine integration (Jinja2).
|
||||
* Request/Response handling (cookies, sessions, headers).
|
||||
* Development server (though not suitable for production).
|
||||
* **Dependency:** Flask uses a library called **Werkzeug**, which is a comprehensive WSGI utility library.
|
||||
|
||||
## 3. Key Differences at a Glance
|
||||
|
||||
| Feature | WSGI | Flask |
|
||||
| :--- | :--- | :--- |
|
||||
| **Type** | Specification / Interface | Web Framework |
|
||||
| **Level** | Low-level (system bridge) | High-level (application code) |
|
||||
| **Purpose** | Standardization and compatibility | Rapid application development |
|
||||
| **Functionality** | Passing data between server and app | Routing, templates, logic, session management |
|
||||
| **Relationship** | Flask is an implementation of a WSGI app | Flask relies on WSGI to talk to the web server |
|
||||
|
||||
## 4. How They Work Together
|
||||
In a typical production environment, the stack looks like this:
|
||||
|
||||
`User Browser` <-> `Web Server (Nginx)` <-> **`WSGI Server (Gunicorn)`** <-> **`Flask App`**
|
||||
|
||||
1. **Nginx** receives the HTTP request.
|
||||
2. **Gunicorn** (the WSGI Server) translates that HTTP request into the WSGI environment format.
|
||||
3. **Flask** receives the WSGI call, routes it to your function, and returns a response.
|
||||
4. **Gunicorn** translates that response back into HTTP for the user.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
aliases:
|
||||
up: "[[00_devop_note]]"
|
||||
tags:
|
||||
- devop
|
||||
---
|
||||
# What is uWSGI?
|
||||
|
||||
**uWSGI** is an application server that sits between a web server (like Nginx or Apache) and a Python web application (like Django, Flask, or FastAPI). It runs your Python code and handles incoming web requests.
|
||||
|
||||
The name comes from **WSGI** (Web Server Gateway Interface), which is the standard Python spec (PEP 3333) that defines how web servers talk to Python applications. The lowercase "u" is the Greek letter μ (micro), suggesting it's lightweight — though in practice it grew into a full-featured server.
|
||||
|
||||
## Why do we need it?
|
||||
|
||||
A plain web server like Nginx doesn't know how to execute Python code. It only serves static files (HTML, CSS, images) and forwards dynamic requests elsewhere. You need a process that:
|
||||
|
||||
1. Loads your Python application into memory
|
||||
2. Receives requests from the web server
|
||||
3. Calls your Python code with the request
|
||||
4. Returns the response back to the web server
|
||||
|
||||
That middle process is uWSGI (or alternatives like Gunicorn).
|
||||
|
||||
## The typical stack
|
||||
|
||||
```
|
||||
Browser → Nginx → uWSGI → Python app (Django/Flask)
|
||||
```
|
||||
|
||||
- **Nginx**: handles SSL, static files, load balancing, gzip, caching
|
||||
- **uWSGI**: runs Python workers, manages processes/threads
|
||||
- **Python app**: your business logic
|
||||
|
||||
Nginx and uWSGI usually talk over a **Unix socket** (fast, local) or a TCP port. The protocol between them is called the **uwsgi protocol** (lowercase) — a binary protocol that's faster than plain HTTP.
|
||||
|
||||
## Key features
|
||||
|
||||
- **Process management**: spawns multiple worker processes to handle concurrent requests
|
||||
- **Threading**: each worker can run multiple threads
|
||||
- **Auto-reload**: restart workers when code changes (dev mode)
|
||||
- **Emperor mode**: one master process supervising many vassal apps
|
||||
- **Cheaper mode**: dynamically scale workers up/down based on load
|
||||
- **Multi-language**: despite the name, also supports Ruby, Perl, Go, etc.
|
||||
|
||||
## Minimal config example
|
||||
|
||||
A typical `uwsgi.ini`:
|
||||
|
||||
```ini
|
||||
[uwsgi]
|
||||
module = myproject.wsgi:application
|
||||
master = true
|
||||
processes = 4
|
||||
threads = 2
|
||||
socket = /tmp/myproject.sock
|
||||
chmod-socket = 660
|
||||
vacuum = true
|
||||
die-on-term = true
|
||||
```
|
||||
|
||||
- `module`: entry point (the WSGI callable)
|
||||
- `processes`: how many worker processes to fork
|
||||
- `socket`: where Nginx connects to
|
||||
- `vacuum`: clean up the socket on exit
|
||||
- `die-on-term`: shut down cleanly on SIGTERM
|
||||
|
||||
## Running it
|
||||
|
||||
```bash
|
||||
uwsgi --ini uwsgi.ini
|
||||
```
|
||||
|
||||
Or in production, run it under **systemd** so it restarts on failure.
|
||||
|
||||
## uWSGI vs Gunicorn
|
||||
|
||||
Both are WSGI servers. The community has largely shifted toward **Gunicorn** because:
|
||||
|
||||
- Simpler config
|
||||
- Fewer footguns
|
||||
- Easier to deploy
|
||||
|
||||
uWSGI is more feature-rich and faster in some benchmarks, but its config surface is huge (hundreds of options) and the project has had governance/maintenance concerns. For new projects, Gunicorn behind Nginx is the common default.
|
||||
|
||||
## When you'll see uWSGI
|
||||
|
||||
- Legacy Django/Flask deployments
|
||||
- Setups that need uWSGI-specific features (Emperor, cheaper, etc.)
|
||||
- Docker images for older Python web apps
|
||||
|
||||
## Related
|
||||
|
||||
- [[Apache Tomcat]] — the Java equivalent role (servlet container running Java apps behind a web server)
|
||||
Reference in New Issue
Block a user