แบ็กเอนด์ Python และ FastAPI — API ที่ทันสมัยและขยายขนาดได้
FastAPI คือเฟรมเวิร์ก Python มาตรฐานสำหรับ REST API แบบอะซิงโครนัส รวม type hints ของ Python เข้ากับการตรวจสอบอัตโนมัติของ Pydantic เอกสาร OpenAPI ที่สร้างอัตโนมัติ และประสิทธิภาพ ASGI แบบอะซิงโครนัส โดยไม่ต้องเสียความอ่านง่ายของโค้ด
FastAPI — เฟรมเวิร์ก Python สำหรับ API
FastAPI รันบน Uvicorn (เซิร์ฟเวอร์ ASGI) ร่วมกับ Gunicorn สำหรับหลายโปรเซสใน production เอนด์พอยต์ง่าย ๆ ที่อ่านจากแคช Redis โดยไม่คิวรีฐานข้อมูลในทุกคำขอ Dependency Injection แบบเนทีฟช่วยให้ทดสอบเลเยอร์ใดก็ได้แบบแยกส่วนโดยไม่ต้องใช้ mock ซับซ้อน ไม่ว่าจะเป็นการยืนยันตัวตน เซสชันฐานข้อมูล หรือ rate limiting ทุกอย่างเป็น dependency ที่ฉีดเข้าไปได้
เอกสาร OpenAPI 3.1 ถูกสร้างอัตโนมัติจาก type hints — มี Swagger UI และ ReDoc ที่ `/docs` และ `/redoc` ในช่วงพัฒนา สคีมา Pydantic v2 (ตัวตรวจสอบที่เขียนด้วย Rust) ตรวจสอบคำขอและการตอบกลับเร็วกว่า Pydantic v1 10–20 เท่า ฟิลด์ที่ไม่ถูกต้องจะตอบกลับ 422 พร้อมข้อความข้อผิดพลาดที่ชัดเจนตามภาษาท้องถิ่น
- async/await แบบเนทีฟ — I/O แบบไม่บล็อกในทุกการทำงานกับ DB และ HTTP
- BackgroundTasks สำหรับงานหลังตอบกลับ (อีเมล, webhook, log)
- รองรับ WebSocket แบบเนทีฟสำหรับฟีเจอร์เรียลไทม์ (แชต, การแจ้งเตือน)
- Rate limiting ด้วย slowapi (อิงตาม limits) — ต่อ IP และต่อผู้ใช้
- CORS, การบีบอัด (gzip/brotli), request ID, timing middleware
PostgreSQL, SQLAlchemy และ Alembic
เราใช้ SQLAlchemy 2.0 แบบ async (ไดรเวอร์ asyncpg) กับทุกการทำงานกับ DB โมเดลกำหนดด้วยไทป์ Mapped — type-safe ไม่ใช้สตริง คิวรีซับซ้อนเขียนด้วย SQLAlchemy Core (ตรวจสอบตอนคอมไพล์) หรือ SQL ล้วนผ่าน `text()` พร้อม bind parameters — ไม่ใช้การต่อสตริงเด็ดขาด (ช่วยป้องกัน SQLi)
การย้ายสคีมาด้วย Alembic ถูกสร้างอัตโนมัติจากการเปลี่ยนแปลงโมเดลและตรวจทานด้วยมือก่อนนำไปใช้ ทุก migration มี `upgrade()` และ `downgrade()` ที่ผ่านการทดสอบ ใน production การย้ายสคีมารันใน CI ก่อนดีพลอย — ฐานข้อมูลจึงตรงกับโค้ดเสมอ มี connection pooling ผ่าน asyncpg โดยกำหนดขนาด pool ต่อเซอร์วิสได้
- Row-level locking ด้วย `SELECT ... FOR UPDATE` สำหรับงานพร้อมกันที่สำคัญ
- Full-text search ด้วย pg_trgm และ tsvector — ไม่ต้องใช้ Elasticsearch ในกรณีง่าย ๆ
- JSONB สำหรับข้อมูลกึ่งโครงสร้างพร้อมดัชนี GIN
- การแบ่งพาร์ทิชันตารางสำหรับตารางที่มีหลายล้านแถว (logs, events)
แคช Redis และการขยายขนาดแนวนอน
Redis 7 ใช้สำหรับแคชแอปพลิเคชัน (TTL ต่อเอนด์พอยต์), session store (JWT refresh tokens พร้อมการเพิกถอนแบบเลือกได้), pub/sub สำหรับอีเวนต์เรียลไทม์ และคิวสำหรับงานเบื้องหลัง (Celery หรือ ARQ) กลยุทธ์แคชคือ cache-aside พร้อม invalidation แบบชัดเจน — ไม่ใช่ TTL แบบสุ่มสี่สุ่มห้าที่อาจให้ข้อมูลล้าสมัย
- การยืนยันตัวตนด้วย JWT: access token (15 นาที) + refresh token ใน Redis (7 วัน)
- Celery + Redis broker สำหรับงานแบบอะซิงโครนัส (สร้าง PDF, อีเมล, การนำเข้าข้อมูล)
- เอนด์พอยต์ health check `/health` แสดงสถานะ DB, Redis และเวอร์ชันที่ดีพลอย
- Structured JSON logging (structlog) — ใช้ร่วมกับ Loki/Datadog/ELK ได้
ข้อดีและข้อจำกัด
ข้อดี
- โมเดล ASGI แบบอะซิงโครนัสเหมาะกับงาน I/O
- เอกสาร OpenAPI สร้างอัตโนมัติจาก type hints
- การตรวจสอบด้วย Pydantic v2 ที่เร็ว พร้อมข้อผิดพลาด 422 ที่ชัดเจน
- โค้ดอ่านง่าย Python คุ้นเคยสำหรับทีมส่วนใหญ่
ข้อจำกัด
- Python ยังช้ากว่า Go หรือ Rust ในงานที่ใช้ CPU หนัก
- async/await ต้องมีวินัย — การเรียกแบบบล็อกเพียงครั้งเดียวทำให้ event loop ทั้งหมดค้าง
- ระบบนิเวศยังใหม่กว่า Django ในด้านฟีเจอร์แบบครบชุด
- ไม่มี ORM หรือแอดมินในตัว — ต้องเลือกแยกต่างหาก
สรุปสั้น ๆ
เลือก FastAPI สำหรับ REST API แบบอะซิงโครนัส ไมโครเซอร์วิส และแบ็กเอนด์สำหรับ SPA/มือถือ หากเป็นแอปที่ใช้ CPU หนักมาก หรือมอนอลิธที่ต้องการแอดมินสำเร็จรูป Go หรือ Django ตามลำดับอาจเหมาะกว่า
ตารางสเปก
| ความสามารถ | ขีดจำกัด / เกณฑ์ | การใช้งานโดยทั่วไป | |
|---|---|---|---|
| การทำงานพร้อมกัน | async/await, I/O แบบไม่บล็อก | งานที่ใช้ CPU หนักต้องใช้ worker แยก | API ที่เรียก DB/HTTP จำนวนมาก |
| เวลาแฝง | ไม่มีคิวรีฐานข้อมูลต่อคำขอเมื่อใช้แคช Redis | เพิ่มขึ้นเมื่อ serialize payload ขนาดใหญ่ | SaaS, มือถือ, แบ็กเอนด์เรียลไทม์ |
| การตรวจสอบและเอกสาร | Pydantic v2 + OpenAPI 3.1 อัตโนมัติ | สคีมาซับซ้อนทำให้เวลาเริ่มต้นนานขึ้น | API สาธารณะที่มี Swagger/ReDoc |
| ค่าใช้จ่ายโดยทั่วไป | โอเพนซอร์ส รันได้บน 1 vCPU | การขยายขนาดแนวนอนต้องใช้โปรเซสเพิ่ม | ตั้งแต่ MVP จนถึง production |
FastAPI เทียบกับทางเลือกอื่น
| เกณฑ์ | FastAPI | Django / Express |
|---|---|---|
| ประสิทธิภาพแบบ async | ยอดเยี่ยม (ASGI แบบเนทีฟ) | Django บางส่วน, Express ดี |
| เอกสาร OpenAPI อัตโนมัติ | มี จาก type hints | ต้องใช้แพ็กเกจเพิ่มเติม |
| แอดมิน / ORM ในตัว | ไม่มี (เลือกแยกต่างหาก) | Django: มี; Express: ไม่มี |
คำถามที่พบบ่อย
FastAPI เร็วกว่า Django หรือไม่?
เร็วกว่าในงาน I/O FastAPI ทำงานแบบ async บน ASGI จึงรองรับคำขอพร้อมกันที่มีการเรียก DB/HTTP ได้มากกว่า Django แบบซิงโครนัสดั้งเดิมมาก แต่ Django มีฟีเจอร์ในตัวมากกว่า
FastAPI ไม่เหมาะกับอะไร?
สำหรับงานที่ใช้ CPU หนัก (ประมวลผลภาพ, คำนวณเชิงตัวเลขหนัก) Python ช้ากว่า Go หรือ Rust จึงควรย้ายงานเหล่านั้นไปไว้ใน worker แยก และไม่มีแอดมินสำเร็จรูปแบบ Django
FastAPI ต้องใช้ ORM หรือไม่?
ไม่บังคับ เราใช้ SQLAlchemy 2.0 แบบ async กับ Alembic สำหรับการย้ายสคีมา แต่คุณเขียน SQL ล้วนก็ได้ ORM ไม่ได้มาพร้อมกัน จึงเลือกได้ตามแต่ละโปรเจกต์
จะขยายขนาดแบ็กเอนด์ FastAPI ได้อย่างไร?
ขยายแนวนอน: รันหลายโปรเซส Uvicorn ภายใต้ Gunicorn หลัง load balancer ใช้แคช Redis และย้ายงานหนักไปที่ Celery การออกแบบแบบ stateless ช่วยให้เพิ่มอินสแตนซ์ได้ตามต้องการ