Бекенд на Python і FastAPI — сучасні та масштабовані API
FastAPI — еталонний Python-фреймворк для асинхронних REST API. Він поєднує нативні type hints Python з автоматичною валідацією Pydantic, автоматично згенерованою документацією OpenAPI та продуктивністю ASGI, зіставною з Node.js, — без шкоди для читабельності коду.
FastAPI — найшвидший Python-фреймворк
FastAPI працює на Uvicorn (ASGI-сервер) разом із Gunicorn для багатопроцесності в продакшені. Простий ендпоінт, що читає дані з кешу Redis, не звертається до БД на кожен запит. Нативне впровадження залежностей (Dependency Injection) дає змогу ізольовано тестувати будь-який шар без складних моків: автентифікація, сесія бази даних, обмеження частоти запитів — усе це залежності, які можна впроваджувати.
Документація OpenAPI 3.1 генерується автоматично з type hints — Swagger UI і ReDoc доступні за адресами `/docs` і `/redoc` у середовищі розробки. Схема Pydantic v2 (валідатор на Rust) перевіряє запити й відповіді у 10–20 разів швидше, ніж Pydantic v1. Будь-яке некоректне поле повертає помилку 422 із зрозумілими локалізованими повідомленнями.
- Нативний async/await — неблокувальне введення-виведення для всіх операцій з БД і HTTP
- BackgroundTasks для операцій після відповіді (email, webhook, логування)
- Нативна підтримка WebSocket для функцій реального часу (чат, сповіщення)
- Обмеження частоти запитів зі slowapi (на основі limits) — за IP і за користувачем
- Middleware для CORS, стиснення (gzip/brotli), ідентифікатора запиту, вимірювання часу
PostgreSQL, SQLAlchemy і Alembic
Для всіх операцій з БД ми використовуємо SQLAlchemy 2.0 async (драйвер asyncpg). Моделі описуються через типи Mapped — типобезпечно, без рядків. Складні запити пишемо на SQLAlchemy Core (перевірка на етапі компіляції) або на чистому SQL через `text()` з bind-параметрами — ніколи через інтерполяцію рядків (повний захист від SQLi).
Міграції Alembic автоматично генеруються зі змін моделей і вручну переглядаються перед застосуванням. Кожна міграція має протестовані `upgrade()` і `downgrade()`. У продакшені міграції виконуються в CI перед деплоєм — база даних завжди синхронізована з кодом. Пул з'єднань через asyncpg із розміром пулу, що налаштовується для кожного сервісу.
- Блокування на рівні рядків через `SELECT ... FOR UPDATE` для критичних конкурентних операцій
- Повнотекстовий пошук на pg_trgm і tsvector — без Elasticsearch для простих випадків
- JSONB для напівструктурованих даних з GIN-індексацією
- Партиціонування таблиць із мільйонами рядків (логи, події)
Кешування Redis і горизонтальне масштабування
Redis 7 використовується для кешу застосунку (TTL для кожного ендпоінта), сховища сесій (refresh-токени JWT з вибірковим відкликанням), pub/sub для подій реального часу та черг для фонових завдань (Celery або ARQ). Стратегія кешування — cache-aside з явною інвалідацією, а не сліпий TTL, який може віддавати застарілі дані.
- Автентифікація JWT з access-токеном (15 хв) + refresh-токеном у Redis (7 днів)
- Celery + брокер Redis для асинхронних завдань (генерація PDF, email, імпорти)
- Ендпоінт перевірки стану `/health` зі статусом БД, Redis і версією деплою
- Структуроване JSON-логування (structlog) — сумісне з Loki/Datadog/ELK
Переваги та обмеження
Переваги
- Продуктивність ASGI, зіставна з Node.js і Go у задачах введення-виведення.
- Документація 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, неблокувальне введення-виведення | CPU-залежні задачі потребують окремих воркерів | API з великою кількістю викликів БД/HTTP |
| Затримка | Читання з кешу Redis без запиту до БД | Зростає при серіалізації великих payload-ів | SaaS-бекенд, мобільні застосунки, реальний час |
| Валідація й документація | Pydantic v2 + автоматична OpenAPI 3.1 | Складна схема збільшує час запуску | Публічні API зі Swagger/ReDoc |
| Типова вартість | Відкритий код, працює на 1 vCPU | Горизонтальне масштабування потребує більше процесів | Від MVP до продакшену |
FastAPI проти альтернатив
| Критерій | FastAPI | Django / Express |
|---|---|---|
| Асинхронна продуктивність | Відмінна (нативний ASGI) | Django — частково, Express — хороша |
| Автоматична документація OpenAPI | Так, з type hints | Потрібні додаткові пакети |
| Вбудована адмінка / ORM | Ні (обираєте окремо) | Django: так; Express: ні |
Поширені запитання
Чи швидший FastAPI за Django?
Так, у задачах введення-виведення. FastAPI працює асинхронно на ASGI, тому обробляє значно більше конкурентних запитів із викликами БД/HTTP, ніж класичний синхронний Django. Проте Django має більше вбудованих функцій.
Для чого FastAPI не підходить?
Для надто CPU-залежних задач (обробка зображень, важкі числові обчислення) Python повільніший за Go чи Rust; такі задачі виносять на окремі воркери. Також він не постачається з готовою адмінкою, як Django.
Чи потрібен FastAPI ORM?
Не обов'язково. Ми використовуємо SQLAlchemy 2.0 async з Alembic для міграцій, але можна писати й чистий SQL. ORM не входить до складу, тож ви обираєте його залежно від проєкту.
Як масштабувати бекенд на FastAPI?
Горизонтально: запускаєте кілька процесів Uvicorn під Gunicorn за балансувальником навантаження, з кешем Redis і важкими завданнями, винесеними на Celery. Stateless-дизайн дає змогу додавати інстанси за потреби.