Django или FastAPI на Cloudflare Workers: что выбрать?

Django или FastAPI на Cloudflare Workers: что выбрать?

Выбирайте Django, если у вас уже есть приложение на Django или нужен полноценный бэкенд продукта. FastAPI лучше подходит для нового типизированного API, сервиса вебхуков или edge-эндпоинта с интенсивным вводом-выводом. Если обязательная библиотека, модель процессов или нагрузка, требующая сохранения состояния, несовместимы со средой Workers, оставьте приложение на текущем origin-сервере — независимо от выбранного фреймворка.

Cloudflare изменила исходные условия 2 сентября 2026 года. Теперь Python Workers могут напрямую запускать приложения WSGI и ASGI через адаптеры модуля workers. WSGI — традиционный синхронный интерфейс для веб-приложений на Python. ASGI — его асинхронный преемник, рассчитанный на параллельное ожидание операций ввода-вывода, потоковую передачу и долгоживущие соединения. В примерах Cloudflare к релизу Django явно связан с WSGI, а FastAPI — с ASGI, хотя Django поддерживает оба протокола.

Django — более безопасный вариант миграции, если встроенные возможности фреймворка уже приносят продукту реальную пользу. Cloudflare документирует точки входа и для WSGI, и для ASGI, а также интеграцию django-cf с D1 и Durable Objects.

FastAPI удобнее для нового проекта, когда результатом должен стать API, а не веб-продукт с админ-панелью. Cloudflare берёт на себя серверный слой ASGI, поэтому Worker не требуется запускать Uvicorn или управлять сокетом.

Цена одинакова, пока не расходится время CPU

По цене самого фреймворка преимущества нет. Данные проверены 5 сентября 2026 года по актуальным первичным источникам: Django распространяется бесплатно с открытым исходным кодом по лицензии BSD, FastAPI использует лицензию MIT, а Workers Paid стоит от $5 за аккаунт в месяц.

В эти $5 входят 10 млн запросов и 30 млн миллисекунд CPU в месяц. Каждый следующий миллион запросов стоит $0.30, а каждый дополнительный миллион миллисекунд CPU — $0.02. Запросы к Static Assets бесплатны и не ограничены. Workers Free включает 100,000 запросов в день, но лимит CPU в 10 ms на один вызов делает этот тариф неудачной отправной точкой для сравнения нетривиальных приложений на фреймворках.

Если привести оба фреймворка к одинаковой нагрузке, результат намеренно скучен. При 15 млн динамических запросов в месяц и среднем времени CPU 7 ms любой из них обойдётся в $8 в месяц: базовые $5, ещё $1.50 за превышение числа запросов и $1.50 за дополнительное время CPU. При 100 млн запросов и тех же средних 7 ms стоимость в обоих случаях составит $45.40 в месяц.

Расчёт чувствительности полезнее выдуманного бенчмарка фреймворков. После исчерпания включённого пула CPU каждая разница в 1 ms среднего времени CPU меняет счёт на $0.30 при 15 млн запросов и на $2 при 100 млн. Таким образом, измеренный разрыв в 5 ms стоит соответственно $1.50 или $10 в месяц. Этого слишком мало, чтобы оправдать переписывание приложения на другом фреймворке исключительно ради цены вычислений.

Точки, в которой цены поставщика расходятся, нет. Один вариант становится дешевле, только если отличается измеренное время CPU, набор вспомогательных сервисов или объём сопровождения. Быстрый фреймворк не спасёт архитектуру с медленными запросами к базе данных, а интегрированный фреймворк, избавляющий от нескольких недель работы по замене компонентов, может оказаться экономичнее, даже если уступает в микробенчмарке.

Миграция: Django выигрывает в готовых системах, FastAPI — в новых API

Адаптер меняется легко, но миграция приложения от этого простой не становится. Обоим фреймворкам достаточно тонкой точки входа, однако всё за ней по-прежнему должно соответствовать модели библиотек, хранилищ, файловой системы и жизненного цикла Cloudflare.

Миграция Django на Cloudflare Workers: адаптер — самая простая часть

Django позволяет сохранить стандартный объект WSGI-приложения и передать его адаптеру Cloudflare:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Этого достаточно, чтобы преобразовать входящий запрос Workers в вызов WSGI-приложения Django. Но такой адаптер не переносит базу данных, постоянные файлы, задания по расписанию, стратегию сессий и все сторонние пакеты Django.

Новое руководство Cloudflare по Django даёт фреймворку действительно нативный путь к хранилищу. Пакет django-cf предоставляет совместимые с SQLite бэкенды для D1 и Durable Objects. Оба работают с синхронной ORM Django, поэтому Cloudflare предписывает обслуживать такую конфигурацию через WSGI. Для CRUD-продукта, уже зависящего от моделей, форм, аутентификации и админ-панели, сохранение этих уровней экономит намного больше работы, чем смена фреймворка могла бы сберечь на стоимости среды выполнения.

Предел обнаруживается, когда существующая система рассчитывает на обычный сервер. Драйвер базы данных может требовать нативный wheel-файл, который Workers не загрузит. Пользовательские загрузки нельзя хранить в файловой системе изолята. Локальный для процесса планировщик или пул потоков перенести не получится. Поддержка Django означает, что протокол запросов работает, но не гарантирует совместимость всего установленного приложения.

Миграция FastAPI на Cloudflare Workers: лучший вариант для узкого сервиса

Прямой адаптер FastAPI ещё компактнее, поскольку фреймворк уже использует ASGI:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare выполняет роль ASGI-сервера, которую обычно берёт на себя Uvicorn. FastAPI сохраняет объявления маршрутов, валидацию Pydantic, внедрение зависимостей и автоматически создаваемую документацию OpenAPI. Поэтому новый обработчик вебхуков, типизированный JSON API или сервис, работающий с привязками, начинает с меньшим объёмом инфраструктуры приложения, чем Django.

Обратная сторона — необходимость собирать систему самостоятельно. FastAPI намеренно не навязывает базу данных или модель данных. В нём также нет встроенной админ-панели для контента, как в Django. Эти компоненты придётся выбрать, проверить каждый пакет на совместимость со средой Workers и самостоятельно поддерживать интеграцию. Для специализированного сервиса это преимущество, а для продукта, операторам которого с первого дня нужен back office, — дополнительные издержки.

Победитель по миграции: Django для приложения, уже написанного на Django; FastAPI для нового API. Переписывать работающую систему с Django на FastAPI лишь потому, что теперь оба фреймворка запускаются на edge-платформе, — ошибочный проект.

WSGI или ASGI в Cloudflare: FastAPI сильнее при конкурентной обработке, у Django есть выбор

Для нового сервиса с интенсивным вводом-выводом модель ASGI подходит лучше, однако для интеграции Django ORM с Cloudflare документирован именно WSGI. Протокол выбирают под нагрузку, а не по общему лозунгу «асинхронность всегда быстрее».

WSGI представляет приложение как синхронный вызываемый объект. Текущий адаптер WSGI от Cloudflare запускает его внутри асинхронного обработчика fetch у Worker, преобразует тело запроса из JavaScript ReadableStream, а затем потоково передаёт клиенту итерируемый ответ приложения. Это слой совместимости для зрелых синхронных приложений, а не второй веб-сервер внутри изолята.

ASGI позволяет приложению ожидать сетевые операции и обращения к хранилищу, не блокируя путь запроса синхронным вызовом. Адаптер Cloudflare также сопоставляет события ASGI WebSocket с Workers WebSockets. FastAPI изначально построен вокруг этой модели. Django тоже умеет с ней работать, поэтому Django и WSGI — не синонимы.

Выбор хранилища способен изменить решение о протоколе. Cloudflare указывает, что бэкенды D1 и Durable Objects для Django работают с синхронной ORM и должны обслуживаться через WSGI. Если Django выбран ради ORM, логичнее следовать этому документированному пути WSGI, чем приклеивать ярлык ASGI к синхронному уровню данных.

В FastAPI асинхронность полезна лишь тогда, когда операции действительно можно совмещать. Эндпоинт, который тратит основное время на последовательную валидацию или ресурсоёмкий код Python, всё равно расходует CPU. Если же эндпоинт ожидает несколько независимых HTTP-операций или обращений к привязкам Cloudflare, выбор ASGI обоснован лучше.

Запуск приложения: сюрприз с lifespan в FastAPI

Сейчас Django поверх WSGI обеспечивает на Workers более предсказуемую модель запуска. FastAPI тоже работает, но его хуки lifespan ведут себя не так, как в долгоживущем процессе Uvicorn.

Cloudflare сокращает холодный запуск Python с помощью снимков при развёртывании. Платформа создаёт изолят V8, подключает Pyodide, исполняет входной модуль Worker и его импорты верхнего уровня, а затем сохраняет снимок памяти WebAssembly. Запрос может загрузить этот снимок вместо полного повторного создания Python-среды. При этом код в глобальной области всё равно должен быть разобран и выполнен в пределах установленного платформой лимита запуска в 1 секунду. Cloudflare напрямую описывает этот жизненный цикл.

Обычный контракт lifespan в FastAPI рассчитан на процесс: код запуска выполняется один раз до начала приёма запросов, а код завершения — один раз после остановки приложения. Текущий исходный код ASGI-адаптера Cloudflare ведёт себя существенно иначе. Его функция fetch запускает ASGI-приложение, отправляет событие запуска lifespan, обрабатывает один запрос, а затем отправляет событие завершения. Комментарий в исходном коде описывает один цикл: запуск до запроса и завершение после него.

В текущем адаптере код lifespan тем самым выполняется в контексте каждого запроса. Загрузка модели, создание пула соединений, прогрев схемы или получение удалённой конфигурации, помещённые туда, могут повторяться вместо однократного выполнения на изолят. Это не повод отказываться от FastAPI. Но работа lifespan должна быть дешёвой и идемпотентной, а безопасную детерминированную инициализацию стоит перенести в код, способный использовать снимок Cloudflare при развёртывании.

В примере Cloudflare WSGI-приложение Django создаётся в области модуля и не проходит цикл lifespan ASGI. Его инициализация входит в глобальный путь запуска, поэтому главным ограничением становится потолок в 1 секунду. Если вы выбираете точку входа ASGI для Django и используете компоненты, зависящие от lifespan, проверяйте их с учётом того же поведения адаптера.

Все Python-фреймворки на Workers упираются в одни ограничения библиотек

Здесь ничья, причём ограничения способны исключить оба фреймворка. Django и FastAPI работают в одной среде Pyodide внутри V8, поэтому ни один из них не обходит границы по пакетам, памяти, файловой системе или запуску.

Согласно документации Cloudflare по пакетам, pywrangler упаковывает зависимости, объявленные в pyproject.toml. Поддерживаются чистые Python-пакеты и пакеты PyEmscripten из PyPI, а также библиотеки, поставляемые вместе с Pyodide. PyEmscripten — формат wheel-файлов для WebAssembly. Cloudflare по-прежнему называет эту экосистему ранней, и для некоторых пакетов совместимых wheel-файлов нет.

Жёсткие ограничения платформы сформулировать легко:

• Распакованный пакет Worker не может превышать 64 MiB ни на Free, ни на Paid.
• Каждый изолят получает 128 MB памяти.
• Глобальный запуск должен завершиться в течение 1 секунды.
• Файловая система Python временная и доступна только конкретному изоляту.
• threading и multiprocessing можно импортировать, но в виртуальной машине WebAssembly они не работают.

Ограничение файловой системы ломает больше миграций, чем можно предположить по сигнатуре адаптера. Временные файлы допустимы. Постоянные пользовательские загрузки, созданные отчёты, SQLite-файлы в роли долговременного состояния и общие дисковые кеши — нет. Долговечные данные следует размещать в D1, Durable Objects, KV или R2 в соответствии с моделью доступа, а не в каталоге, исчезающем вместе с изолятом. Точные границы приведены в руководстве Cloudflare по стандартной библиотеке Python.

Совместимость пакетов — бинарное условие, которое важнее производительности. Собирайте реальный граф зависимостей, а не урезанный пример уровня hello world. Успешный импорт в настольном CPython ничего не доказывает о доступности нативных расширений в Pyodide.

Эксплуатационная модель: Django для продуктов, FastAPI для сервисов

Django выигрывает, когда единица разработки — продукт; FastAPI — когда это сервис. Такое различие надёжнее, чем пропускная способность фреймворка на синтетическом маршруте.

Победитель для продукта с админ-панелью: Django

Django включает аутентификацию пользователей, управление контентом, ORM, шаблоны, middleware и другие распространённые компоненты веб-продукта. В официальном обзоре отдельно упоминаются аутентификация и администрирование контента. Если небольшой операционной команде нужно управлять клиентами, заказами, правами доступа и редакционными материалами, встроенная админ-панель может быть ценнее нескольких миллисекунд, сэкономленных на накладных расходах фреймворка.

На Workers пакет django-cf связывает эту интегрированную модель с D1 или Durable Objects. Цена такого удобства — более тесная привязка к синхронной ORM и более крупная поверхность фреймворка, которую необходимо вписать в ограничения среды.

Победитель для типизированного API-сервиса: FastAPI

FastAPI строится вокруг OpenAPI, JSON Schema, валидации Pydantic и внедрения зависимостей. Документация возможностей FastAPI также ясно показывает компромисс: база данных и модель данных остаются на выбор разработчика. Такая архитектура подходит шлюзу API, обработчику вебхуков, эндпоинту модели или небольшому сервису, который обращается к привязкам и удалённым API.

Отсутствие встроенных админ-панели и ORM не является недостатком, пока они не нужны сервису. Но как только специалисту без технической подготовки требуется back office, их отсутствие превращается в дополнительные расходы на разработку.

Победитель по чистой скорости: не определён на Workers

Независимый набор тестов TechEmpower исторически относил FastAPI под Uvicorn к самым быстрым Python-фреймворкам — об этом говорится на странице бенчмарков FastAPI. TechEmpower измерял стандартизированные нагрузки для JSON, баз данных, ORM, шаблонов и связанных сценариев. Он не тестировал адаптеры Pyodide от Cloudflare, а 24 марта 2026 года проект был закрыт. Поэтому результаты остаются историческим сигналом со ссылкой на источник, но не прогнозом для развёртывания на Workers.

Cloudflare не публиковала сравнение Django и FastAPI через эти адаптеры. Следовательно, преимущество в чистой скорости на Workers не доказано, пока репрезентативный маршрут не учитывает собственную валидацию, привязки, запросы к базе данных, формат ответа, поведение при запуске и метрики CPU Workers.

Реальная стоимость перехода и кому он не нужен

Не меняйте фреймворк только ради поддержки Cloudflare: теперь она есть у обоих. Переход оправдан, лишь когда целевой фреймворк устраняет больше работы над приложением, чем создаёт сама миграция.

При переписывании Django на FastAPI придётся заменять или отделять модели, миграции, админ-интерфейсы, сценарии аутентификации, middleware, шаблоны и все пакеты, зависящие от жизненного цикла запросов Django. Для узкого API результат может оказаться отличным, но это не переключатель развёртывания. Если админ-панель и ORM активно используются, такой переход сначала уничтожает имеющееся преимущество и лишь потом создаёт новое.

Переезд с FastAPI на Django имеет смысл, только если продукт перерос сервисную архитектуру и нуждается во встроенных операционных возможностях Django. В противном случае появятся соглашения и компоненты, которые небольшому API не требуются.

FastAPI умеет монтировать WSGI-приложение Django по отдельному пути через a2wsgi.WSGIMiddleware. На обычных серверах это позволяет поэтапно разделять систему. На Workers подход добавляет ещё один пакет и границу между протоколами, тогда как стартовые руководства Cloudflare описывают фреймворки по отдельности. Комбинированный Worker следует считать нестандартной интеграцией, которую нужно доказать на практике, а не готовым способом сократить миграцию.

При любом направлении перехода оцените стоимость следующих частей:

• Данные: совместимость схем, миграции, поведение транзакций и перенос в D1, Durable Objects или другое доступное хранилище.
• Файлы: статические ресурсы можно разместить в Workers Static Assets, а постоянные пользовательские материалы требуют долговечного объектного хранилища, например R2.
• Фоновая работа: замените локальные для процесса планировщики, пулы потоков и дочерние процессы асинхронными механизмами платформы.
• Зависимости: проверьте полный lock-файл в Python Workers, затем измерьте размер пакета относительно лимита 64 MiB и результат запуска за 1 секунду.
• Эксплуатация: заново настройте логи, оповещения об ошибках, откат развёртывания, секреты и базовые показатели производительности для каждого маршрута.

Кому не стоит переходить? Стабильный монолит Django с работающей базой данных и развитым процессом через админ-панель не нужно превращать в FastAPI ради моды. Сервис FastAPI, зависящий от недоступных нативных wheel-файлов, не следует переносить на Workers только потому, что у фреймворка появилась страница в документации. Команде, у которой задержка определяется удалённой базой данных, стоит сначала изменить размещение данных, а уже затем — фреймворк обработки запросов.

Что сделать в понедельник

На следующей неделе проверьте один репрезентативный маршрут, а не всё приложение. Выберите маршрут, отражающий требования рабочей системы к пакетам, состоянию и задержке, а затем быстро исключите с его помощью неподходящие варианты.

FAQ: Django и FastAPI на Cloudflare Workers