<b>Convex хорош, пока вы не упёрлись в модель данных и фоновые задачи</b>

<b>Convex хорош, пока вы не упёрлись в модель данных и фоновые задачи</b>

Convex часто берут как «бэкенд без боли»: realtime, CRUD, auth-обвязка и серверные функции в одном месте. Для небольшого продукта это реально ускоряет старт: меньше сервисов, меньше шансов сломать интеграцию на ровном месте.

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

На практике полезно оценить три вещи:
— как часто нужны массовые выборки и фильтры по нескольким полям;
— можно ли жить в его модели реактивного чтения без костылей;
— кто будет поддерживать миграции и границы между клиентом и сервером.

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

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