mirror of
https://github.com/Rainyy21/framework_note.git
synced 2026-10-11 00:30:29 -04:00
vault backup: 2026-06-01 23:17:01
This commit is contained in:
+1
-1
@@ -13,7 +13,7 @@ All notes under `note/LLM/`, grouped by subfolder.
|
|||||||
|
|
||||||
```dataview
|
```dataview
|
||||||
LIST rows.file.link
|
LIST rows.file.link
|
||||||
FROM "note/LLM"
|
FROM "saveToGit/note/LLM"
|
||||||
WHERE file.name != "index"
|
WHERE file.name != "index"
|
||||||
GROUP BY file.folder
|
GROUP BY file.folder
|
||||||
SORT file.folder ASC
|
SORT file.folder ASC
|
||||||
|
|||||||
@@ -13,7 +13,7 @@ All notes under `note/python/`, grouped by subfolder.
|
|||||||
|
|
||||||
```dataview
|
```dataview
|
||||||
LIST rows.file.link
|
LIST rows.file.link
|
||||||
FROM "note"
|
FROM "saveToGit/note"
|
||||||
WHERE file.name != "index"
|
WHERE file.name != "index"
|
||||||
GROUP BY file.folder
|
GROUP BY file.folder
|
||||||
SORT file.folder ASC
|
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,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.
|
||||||
@@ -4,7 +4,6 @@ up: "[[00_devop_note]]"
|
|||||||
tags:
|
tags:
|
||||||
- devop
|
- devop
|
||||||
---
|
---
|
||||||
w
|
|
||||||
# What is uWSGI?
|
# 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.
|
**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.
|
||||||
Reference in New Issue
Block a user