Для приложения с ИИ backend выбирают по характеру запроса и ограничениям среды выполнения. Короткая операция — проверить форму, вызвать модель и вернуть результат — может уложиться в функцию. Долгая обработка, очередь задач или постоянное соединение могут потребовать отдельного процесса или сервиса. Это зависит от фактических лимитов платформы, а не от ярлыка «serverless».
Проследи запрос и его отказ
Нарисуй последовательность: браузер отправляет текст → сервер проверяет вход → вызывает модель → сохраняет результат → отвечает. Отметь время каждого шага, таймаут и исход, если запись в базу не удалась после платного вызова. Повторный запрос не должен незаметно запускать вторую генерацию; реши, нужен ли идемпотентный ключ. Если клиент отключился, он должен уметь узнать состояние операции.
Для короткого запроса функция может вернуть ответ синхронно. Для batch-обработки документов API может создать job с ID и состояниями queued → processing → complete/failed, а отдельный worker выполнит работу. Это пример схемы, не запущенная интеграция. Секрет модели остаётся на сервере; браузер не должен получать provider key.
Матрица требований к среде
| Сценарий | Что проверить |
|---|---|
| Короткий API вызов | Время CPU и общий timeout относительно вызова модели |
| Потоковый ответ | Поддержка streaming и поведение промежуточного proxy |
| Фоновая генерация | Durable queue, повторная доставка и идемпотентность |
| WebSocket/долгое соединение | Лимит соединений и восстановление при смене экземпляра |
| Большой файл | Размер тела, приватное хранение и проверка типа/размера |
| Секрет провайдера | Серверная передача, ротация и ограничение доступа |
Serverless-функция всё равно запускается на инфраструктуре. Сравни конкретные лимиты времени, памяти, объёма запроса, concurrency и доступности состояния; постоянно работающий процесс добавляет обслуживание, масштабирование и обновления. Для примера, актуальные ограничения публикует Cloudflare Workers, а Supabase Way объясняет границы его backend-компонентов. Это разные продуктовые модели, а не универсальные рейтинги.
Выбери минимальную подходящую схему
Проверь лимиты нужного тарифа и региона, доступ к базе, очередь, логи, локальную разработку и сетевой путь к model provider. Для синхронного ответа зафиксируй таймаут и внешний API error; для фоновой задачи — отмену, повтор, частичную ошибку записи и восстановление статуса. Учитывай не только число запросов: batch может упереться в память или CPU, а long polling — в соединения.
Для MVP начни с самого простого решения, которое выдерживает целевой workflow и правила доступа. Добавляй очередь, постоянный процесс или отдельную платформенную часть, только если есть измеримое требование. Запиши критерии пересмотра: операция превышает лимит времени, требуется durable queue или нужна последовательность транзакций. Так последующая миграция отвечает на наблюдённую проблему, а не на абстрактную «готовность к масштабу».