Convex удобен не когда «быстро стартуем», а когда не хотим писать свой бэкенд-скелет

Convex удобен не когда «быстро стартуем», а когда не хотим писать свой бэкенд-скелет

Convex — это backend-as-a-service с упором на реактивные данные: запросы, мутации, функции и подписки живут рядом, а клиент получает изменения без ручной возни с polling и websocket-обвязкой.

За что его любят:
— меньше glue-кода между фронтом и сервером;
— проще строить live-UI, чаты, дашборды, админки;
— удобный DX для маленькой команды, где каждый час разработки дорог.

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

Сравнивать его стоит не с «обычным API», а с связкой из базы, realtime-слоя и части бэкенда. Если проект — MVP, SaaS с живыми экранами или внутренний инструмент, Convex часто экономит недели. Если нужен контроль над инфраструктурой и запросами на уровне ядра, лучше оставить его для прототипа или отдельных модулей.

Практика простая: берите Convex там, где важны скорость доставки и синхронизация состояния, и избегайте его там, где архитектура уже завязана на сложную SQL-логику и строгую переносимость.