Convex: когда BaaS нужен не ради базы, а ради сложной бизнес-логики

Convex: когда BaaS нужен не ради базы, а ради сложной бизнес-логики

Convex часто берут как «ещё один backend без сервера», но его сильная сторона не в том, чтобы просто хранить записи. Он полезен там, где данные и действия должны жить рядом: подписки, чаты, уведомления, очереди, правила доступа, реактивные обновления в UI.

Главный чек перед стартом:
— если у вас CRUD и пара таблиц, Convex может быть лишним;
— если нужен realtime без ручной склейки WebSocket, это уже его территория;
— если логика должна выполняться на сервере и сразу триггерить обновление клиента, Convex экономит много glue-кода.

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

Отдельно смотрите на vendor lock-in. Чем больше вы завязываете правила, запросы и реактивность на специфичный слой платформы, тем дороже миграция. Для старта это нормально, если заранее держать в голове простой план выхода: где лежат критичные данные, как их экспортировать, что будет без realtime.

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