Bahagian belakang Python & FastAPI — API moden dan berskala
FastAPI ialah rangka kerja Python rujukan untuk API REST tak segerak. Ia menggabungkan petunjuk jenis Python asli dengan pengesahan Pydantic automatik, dokumentasi OpenAPI yang dijana secara automatik dan prestasi ASGI setanding Node.js — tanpa mengorbankan kebolehbacaan kod.
FastAPI — rangka kerja Python moden untuk API
FastAPI berjalan di atas Uvicorn (pelayan ASGI) dengan Gunicorn untuk berbilang proses dalam pengeluaran. Endpoint ringkas yang membaca daripada cache Redis memberi respons dari memori. Dependency Injection asli membolehkan pengujian terasing bagi mana-mana lapisan tanpa mock yang kompleks: pengesahan, sesi pangkalan data, pengehadan kadar — masing-masing ialah kebergantungan yang boleh disuntik.
Dokumentasi OpenAPI 3.1 dijana secara automatik daripada petunjuk jenis — Swagger UI dan ReDoc tersedia di `/docs` dan `/redoc` semasa pembangunan. Skema Pydantic v2 (pengesah berasaskan Rust) mengesahkan permintaan dan respons 10–20x lebih pantas daripada Pydantic v1. Mana-mana medan tidak sah memulangkan 422 dengan mesej ralat yang jelas dan setempat.
- async/await asli — I/O tidak menyekat pada semua operasi DB dan HTTP
- BackgroundTasks untuk operasi selepas respons (e-mel, webhook, log)
- Sokongan WebSocket asli untuk ciri masa nyata (sembang, pemberitahuan)
- Pengehadan kadar dengan slowapi (berasaskan limits) — mengikut IP dan pengguna
- CORS, pemampatan (gzip/brotli), request ID, middleware pemasaan
PostgreSQL, SQLAlchemy dan Alembic
Kami menggunakan SQLAlchemy 2.0 async (pemacu asyncpg) untuk semua operasi DB. Model ditakrifkan dengan jenis Mapped — selamat jenis, tanpa string. Pertanyaan kompleks ditulis dalam SQLAlchemy Core (disemak semasa kompilasi) atau SQL tulen melalui `text()` dengan parameter bind — tidak pernah interpolasi string (pencegahan SQLi sepenuhnya).
Migrasi Alembic dijana secara automatik daripada perubahan model dan disemak secara manual sebelum diterapkan. Setiap migrasi mempunyai `upgrade()` dan `downgrade()` yang diuji. Dalam pengeluaran, migrasi dijalankan dalam CI sebelum penerapan — pangkalan data sentiasa selaras dengan kod. Connection pooling melalui asyncpg dengan saiz pool yang boleh dikonfigurasi bagi setiap perkhidmatan.
- Row-level locking dengan `SELECT ... FOR UPDATE` untuk operasi serentak yang kritikal
- Carian teks penuh dengan pg_trgm dan tsvector — tanpa Elasticsearch untuk kes mudah
- JSONB untuk data separa berstruktur dengan pengindeksan GIN
- Jadual berpartisi untuk jadual dengan berjuta-juta baris (log, peristiwa)
Caching Redis dan kebolehskalaan mendatar
Redis 7 digunakan untuk cache aplikasi (TTL bagi setiap endpoint), simpanan sesi (token refresh JWT dengan pembatalan terpilih), pub/sub untuk peristiwa masa nyata dan baris gilir untuk tugas latar belakang (Celery atau ARQ). Strategi caching ialah cache-aside dengan pembatalan eksplisit — bukan TTL buta yang boleh menghidangkan data lapuk.
- Pengesahan JWT dengan access token (15min) + refresh token Redis (7 hari)
- Celery + broker Redis untuk tugas tak segerak (penjanaan PDF, e-mel, import)
- Endpoint health check `/health` dengan status DB, Redis dan versi penerapan
- Pengelogan JSON berstruktur (structlog) — serasi dengan Loki/Datadog/ELK
Kelebihan dan kekurangan
Kelebihan
- Prestasi ASGI setanding Node.js dan Go pada I/O.
- Dokumentasi OpenAPI dijana automatik daripada petunjuk jenis.
- Pengesahan Pydantic v2 yang pantas, dengan ralat 422 yang jelas.
- Kod mudah dibaca, Python biasa bagi kebanyakan pasukan.
Had
- Python kekal lebih perlahan daripada Go atau Rust pada tugas intensif CPU.
- async/await memerlukan disiplin — satu panggilan menyekat boleh menghentikan keseluruhan gelung peristiwa.
- Ekosistem lebih muda daripada Django untuk ciri serba lengkap.
- Tiada ORM atau admin terbina dalam — anda memilihnya secara berasingan.
Rumusan ringkas
Pilih FastAPI untuk API REST tak segerak, perkhidmatan mikro dan bahagian belakang untuk SPA/mudah alih. Untuk aplikasi terikat CPU yang ekstrem atau monolit dengan admin siap pakai, masing-masing Go atau Django mungkin lebih sesuai.
Jadual spesifikasi
| Keupayaan | Had / ambang | Kegunaan biasa | |
|---|---|---|---|
| Keserentakan | async/await, I/O tidak menyekat | Tugas terikat CPU memerlukan worker berasingan | API dengan banyak panggilan DB/HTTP |
| Kependaman | Respons dari memori bagi endpoint dengan cache Redis | Meningkat dengan bersiri muatan besar | SaaS, mudah alih, bahagian belakang masa nyata |
| Pengesahan & dokumen | Pydantic v2 + OpenAPI 3.1 automatik | Skema kompleks menambah masa permulaan | API awam dengan Swagger/ReDoc |
| Kos biasa | Sumber terbuka, berjalan pada 1 vCPU | Penskalaan mendatar memerlukan lebih banyak proses | Daripada MVP hingga pengeluaran |
FastAPI berbanding alternatif
| Kriteria | FastAPI | Django / Express |
|---|---|---|
| Prestasi tak segerak | Cemerlang (ASGI asli) | Django separa, Express baik |
| Dokumen OpenAPI automatik | Ya, daripada petunjuk jenis | Memerlukan pakej tambahan |
| Admin / ORM terbina dalam | Tidak (pilih secara berasingan) | Django: ya; Express: tidak |
Soalan lazim
Apakah perbezaan utama antara FastAPI dan Django?
FastAPI berjalan secara tak segerak pada ASGI, jadi ia sesuai untuk banyak panggilan DB/HTTP serentak. Django mempunyai lebih banyak ciri terbina dalam.
Untuk apa FastAPI tidak sesuai?
Untuk tugas yang sangat terikat CPU (pemprosesan imej, pengiraan numerik berat) Python lebih perlahan daripada Go atau Rust; anda memindahkannya ke worker berasingan. Ia juga tiada admin siap pakai seperti Django.
Adakah FastAPI memerlukan ORM?
Tidak wajib. Kami menggunakan SQLAlchemy 2.0 async dengan Alembic untuk migrasi, tetapi anda boleh menulis SQL tulen. ORM tidak dibundel, jadi anda memilihnya bagi setiap projek.
Bagaimana saya menskalakan bahagian belakang FastAPI?
Secara mendatar: jalankan berbilang proses Uvicorn di bawah Gunicorn di belakang pengimbang beban, dengan cache Redis dan tugas berat dipindahkan ke Celery. Reka bentuk tanpa state membolehkan anda menambah instans mengikut keperluan.