Как разработчик VideoCaptions.AI, я столкнулся с классической проблемой роста: мой сервис, бесплатный генератор субтитров на основе ИИ, начал получать неожиданный трафик. Проект, построенный на React Router v7 с SSR, использующий аутентификацию, Convex для бэкенда, Remotion для рендеринга видео и несколько AI-сервисов для распознавания речи, работал на Vercel. И всё было хорошо, пока в один из выходных не произошёл резкий всплеск активности.
Превышение лимитов Vercel: точка невозврата
Проблема возникла внезапно. Vercel просто перестал обрабатывать запросы во время трафикового пика. Бесплатный тариф предлагает 100 ГБ пропускной способности и ограниченное количество CPU-часов, но мои серверно-рендерящиеся SEO-страницы плюс API-маршруты (которые вызывают AI-сервисы) расходовали вычислительные ресурсы быстрее, чем я предполагал.
Ирония ситуации заключалась в том, что это был положительный сигнал: приложение набирало популярность. Однако мне потребовалось хостинговое решение, которое не наказывало бы за успех. Поскольку Cloudflare уже присутствовал в моём стеке (домен был зарегистрирован там, я использовал R2 для хранения файлов, и мой существующий Worker для загрузки уже работал на их платформе), переход остальных компонентов казался естественным следующим шагом вместо оплаты $20 в месяц за Vercel Pro.
Архитектурные особенности мигрируемого приложения
Переезду подлежало не просто лендинг-пейдж. Приложение обладало сложной структурой:
- React Router v7 в режиме фреймворка с SSR
- Более 80 пререндеренных SEO-страниц (страницы платформы, сравнения с конкурентами, языковые страницы)
- 5 API-маршрутов, которые обращаются к ElevenLabs для преобразования речи в текст, OpenAI для сегментации клипов с помощью LLM и Groq в качестве резервного провайдера транскрипции
- Аутентификация с проверкой JWT как на клиенте, так и на сервере
- Convex в качестве базы данных (биллинг, кредиты, хранилище проектов)
- Remotion для точного построения видео и экспорта MP4
- Upstash Redis для ограничения скорости API-запросов
Вся система представляет собой монорепозиторий с 12 приложениями и 23 общими пакетами. Переезжало только приложение для создания субтитров — всё остальное оставалось на Vercel.
Основные сложности миграции
Первой и наиболее очевидной проблемой стала разница в архитектурных подходах. Vercel предлагает бесшовную интеграцию с Next.js и подобными фреймворками, в то время как Cloudflare Workers требуют более явной настройки для серверного рендеринга.
Для реализации SSR на Cloudflare Workers потребовалось создать кастомное решение для обработки маршрутов React Router. В Vercel это работало "из коробки", но в Workers пришлось вручную настраивать обработку запросов, рендеринг компонентов и отправку HTML-ответов.
Вторая проблема касалась управления зависимостями. Некоторые пакеты, отлично работавшие в Node.js-окружении Vercel, оказались несовместимыми со средой выполнения Cloudflare Workers. Особенно это касалось библиотек, активно использующих нативные модули Node.js или файловую систему.
Третьим вызовом стала работа с API-маршрутами. В Vercel они автоматически масштабировались и управлялись платформой. В Cloudflare Workers пришлось самостоятельно реализовывать логику маршрутизации, обработки ошибок и управления состоянием.
Решения для критических проблем
Для SSR на React Router v7 я создал собственный адаптер, который перехватывает запросы, определяет соответствующий маршрут React, рендерит компонент и возвращает HTML. Ключевым моментом стала правильная обработка статических ресурсов и метаданных для SEO-страниц.
Проблему с зависимостями решил тщательный аудит пакетов и поиск альтернатив, совместимых со средой выполнения Workers. Для некоторых критически важных библиотек пришлось создавать обёртки или искать обходные пути.
API-маршруты были реорганизованы в отдельные Workers или сгруппированы в одном Worker с условной логикой маршрутизации. Это потребовало пересмотра структуры endpoints, но в итоге дало больше контроля над обработкой запросов.
Особое внимание пришлось уделить работе с внешними сервисами. Вызовы к ElevenLabs, OpenAI и Groq требовали правильной настройки таймаутов, повторных попыток и обработки ошибок, поскольку среда Workers имеет свои особенности работы с внешними HTTP-запросами.
Оптимизация производительности
После решения основных проблем миграции я сосредоточился на оптимизации. Cloudflare Workers предлагают несколько уникальных возможностей для улучшения производительности:
Кэширование на граничной сети стало мощным инструментом для SEO-страниц. Поскольку контент этих страниц меняется нечасто, я настроил агрессивное кэширование с соответствующими заголовками, что значительно снизило нагрузку на Workers и ускорило отдачу контента.
Для API-маршрутов, вызывающих AI-сервисы, я реализовал стратегию кэширования результатов дорогостоящих операций, таких как транскрипция видео. Это не только уменьшило количество вызовов к внешним API, но и значительно улучшило пользовательский опыт для повторяющихся запросов.
Управление соединениями с базой данных Convex потребовало особого внимания. В отличие от традиционных серверных сред, Workers имеют ограничения на время выполнения и использование памяти, поэтому пришлось оптимизировать запросы и минимизировать время установки соединения.
Результаты перехода
Миграция с Vercel на Cloudflare Workers потребовала значительных усилий, но результаты оправдали ожидания. Производительность приложения улучшилась, особенно для пользователей из разных географических регионов, благодаря глобальной сети Cloudflare.
Стоимость эксплуатации снизилась, так как модель ценообразования Workers оказалась более предсказуемой для моего случая использования. Возможность тонкой настройки кэширования и оптимизации каждого аспекта приложения дала уровень контроля, недоступный на Vercel.
Важным уроком стало понимание, что миграция между облачными платформами — это не просто копирование кода. Это глубокий анализ архитектурных различий, адаптация к новым парадигмам и переосмысление подходов к решению привычных задач. Для разработчиков, рассматривающих подобный переход, я рекомендую начинать с тщательного планирования, создания proof-of-concept для самых критических компонентов и постепенной миграции, а не "большого взрыва".