<b>Convex удобен, пока не начинаешь тащить в него всё подряд: где ломается модель</b>

<b>Convex удобен, пока не начинаешь тащить в него всё подряд: где ломается модель</b>

Convex хорошо заходит для приложений, где важны быстрые CRUD-операции, подписки на изменения и минимум ручной возни с бэком. Но его сильная сторона — не «замена всему», а очень быстрый путь от схемы к рабочему продукту.

Есть наблюдение которое стоит проверить:
— если логика живёт рядом с данными и запросы простые, Convex экономит много времени;
— если у вас сложные джоины, отчётность, тяжёлые выборки и много интеграций — начинаются компромиссы;
— если команда любит явные контракты и долгую поддержку, заранее продумайте, где будет граница между Convex и отдельным API.

Главная ошибка — держать в Convex всё подряд: авторизацию, бизнес-логику, фоновые задачи, внешние webhooks и ещё админку. Так система выглядит цельной только на старте, а потом превращается в набор скрытых зависимостей.

Хорошая схема обычно такая:
— Convex для realtime-данных, сессий, простых операций и реактивного UI;
— отдельный сервис для тяжёлых интеграций и нестабильных внешних API;
— явный слой доменной логики, если проекту нужен переносимый backend.

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