Convex: когда нужен backend без ручной сборки API, но с SQL-подобной моделью

Convex часто берут как «серверless для продукта», где не хочется писать отдельный REST-слой, вручную синхронизировать стейт и жить на костылях вокруг realtime. Суть простая: данные, запросы и мутации живут рядом, а клиент получает реактивные обновления без отдельного websocket-ада.

Что обычно получает команда:
— единый способ хранить и читать данные;
— удобный realtime для чатов, дашбордов, live-форм;
— меньше glue-кода между фронтом и бэком;
— быстрый старт для CRUD, админок и внутренних тулов.

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

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

Вывод простой: Convex берут не «вместо всего», а чтобы быстро собрать живой продукт там, где realtime и скорость разработки важнее классического бэкенд-контроля.

Cloudflare Workers: где они реально выигрывают у обычного backend и где ломаются

Workers берут не «серверless ради моды», а когда нужен короткий путь от запроса до ответа: edge-логика, редиректы, A/B-проверки, подмена заголовков, лёгкий API-gateway, кэширование и фильтрация трафика. Для этих задач они часто проще, чем поднимать отдельный сервис на VM или в контейнере.

Но есть три типичных ограничения, о которых вспоминают слишком поздно: — нет привычного долгого stateful-процесса; — нельзя бездумно тащить тяжёлые нативные зависимости; — любая работа, которая держится на постоянных соединениях и фоновых джобах, требует другой архитектуры. Если задача выглядит как «пока ждём 30 секунд и считаем», это уже не их зона.

Хорошее правило: Workers ставят на входе системы, а не в её сердце. То есть они удобны для авторизации на краю, маршрутизации, rate limit, простых интеграций и glue-кода между сервисами. Если нужна база, очередь или транзакционная логика — вынеси это в отдельный backend, а Worker оставь тонким слоем.

Ещё одна частая ошибка — пытаться хранить в Worker то, что должно жить в внешнем storage. Для временных данных используй кэш, KV или Durable Objects только там, где нужна координация. Иначе получишь код, который сложно тестировать и ещё сложнее мигрировать.

Если проекту нужен быстрый edge-слой без лишней инфраструктуры, Workers — сильный выбор. Если ядро продукта уже завязано на сложный runtime, не пихай туда всё подряд: тонкий Worker почти всегда полезнее, чем «мини-монолит» на краю.

Resend хорош не как «ещё один SMTP», а как способ не трогать почту руками

Если у вас транзакционные письма, Resend закрывает три вещи: нормальный API, понятные шаблоны и вменяемую доставляемость без плясок вокруг SMTP-логина. Для продуктовой команды это удобнее, чем держать самописный mailer и потом ловить письма в спаме.

Что обычно делают через него:
— подтверждение почты и сброс пароля;
— системные уведомления из SaaS;
— письма из форм, вебхуков и CRM-цепочек;
— простую сегментацию по событиям без тяжёлой рассылочной платформы.

На что смотреть перед интеграцией:
— есть ли у вас отдельный домен или поддомен под отправку;
— умеет ли шаблон жить без верстки в стиле «один большой HTML-ад»;
— нужны ли вам только письма, или ещё массовые кампании, A/B и сложная аналитика;
— как вы будете обрабатывать bounce, spam complaint и повторную отправку.

Главный плюс Resend — он не заставляет собирать почтовую инфраструктуру как конструктор из трёх сервисов. Главный минус — если вам нужна тяжёлая маркетинговая машина, это уже другой класс инструмента.

Лучше всего Resend заходит там, где письмо — часть продукта, а не отдельный канал продаж: подключили, проверили домен, прописали retry и забыли о нём до первого инцидента.

Neon берут не за «модную Postgres», а за миграцию без лишней боли

Neon — это managed Postgres с раздельными compute и storage. Для команды это означает не «ещё одна база», а другой способ жить с базой: ветки, быстрые копии окружений и меньше ручной возни при тестах.

Где он полезен:
— когда нужны preview-окружения под каждый PR;
— когда dev/stage/prod надо клонить без долгого дампа;
— когда хочется быстро откатить схему через отдельную ветку, а не через героизм в пятницу.

На что смотреть до переезда:
— есть ли у вас тяжёлые миграции и фоновые джобы, которые любят долгие соединения;
— насколько приложение чувствительно к latency: serverless-архитектура и удалённая БД иногда добавляют заметную задержку;
— умеет ли ваш ORM/миграционный инструмент работать без сюрпризов с pooled connections и короткими коннектами.

Главная ошибка — думать, что Neon спасёт плохую дисциплину в схеме. Если миграции грязные, индексы не продуманы, а соединения открываются как попало, новая платформа не исправит это сама. Зато хорошая схема ветвления быстро показывает, где у вас реальная причина боли.

Если нужна база, которая упрощает изоляцию окружений и работу с preview, Neon часто выигрывает не ценой, а организацией процесса.

Vercel удобен до первого спора о бюджете, билдах и том, кто платит за трафик

Если команда живёт на Next.js и хочет деплой без лишней возни — это сильный дефолт. Но Vercel надо оценивать не по “красоте” интерфейса, а по трём вещам: где у вас рендер, сколько запросов уходит в edge/serverless, и что будет при росте медиа или API.

На практике чаще всего ломается не код, а ожидания:
— превью-среда есть у всех, но тестировать надо не только UI, а переменные окружения, webhooks и редиректы;
— статике легко, а вот тяжёлые SSR-страницы и фоновые задачи быстро упираются в лимиты платформы;
— если проект начинает жить на динамике, проверьте стоимость каждого “удобного” запроса, а не только общую сумму.

Ещё один частый промах — пытаться держать на Vercel всё подряд. Файлы, очереди, long-running jobs и сложную обработку медиа лучше сразу выносить в отдельный слой: object storage, worker, БД и кэш. Тогда платформа остаётся для фронта и edge-логики, а не превращается в универсальный комбайн.

Если нужен быстрый старт и чистый DX — Vercel почти всегда оправдан. Если проект уже считает деньги и нагрузку, сначала нарисуйте карту “страница → запросы → внешний сервис”, иначе удобный деплой начнёт скрыто съедать маржу.

1. Выкатить ни какую он-лайн конфу я естесвенно не выкатил, потерпите

2. После прошлого видео (тык) мой канал теперь имеет юзер @PO_YICA_BRAL

3. Держите вечернее видео, я нажрусь и спать

Чото надо ещё сказать? Ну, можно лишь добавить Настя #MelBet верни деньги, не играй с огнём, со мной лучше не ссориться. Спасибо.

P.S. Бабка-то, похоже, не своей..... см. видео!

С уважением, Иванов Е.Ю!

🎁 РОЗЫГРЫШ $2000 ОТ SERG ACCS

🥇 1 место — $1000
🥈 2 место — $700
🥉 3 место — $300

Как участвовать:
1️⃣ Подпишитесь на канал
2️⃣ Нажмите «✅ Участвую»
3️⃣ Получите 1 стартовый билет

Больше билетов:
🛒 Покупки — минимум 1 билет, далее +1 за каждые полные $50 реальной оплаты. Максимум — 50.
👥 Рефералы — +5 за первую подходящую покупку друга и +1 за каждые накопленные $100 его покупок. Максимум — 50.

Общий максимум — 100 билетов.
Чем больше билетов, тем выше шанс. Даже 1 билет участвует.

Призы начислим на баланс в боте SERG ACCS.

Итоги 15.09. Всем удачи! 🔥

Почему Sentry шумит не из-за багов, а из-за плохой настройки фильтров

Sentry полезен только когда он показывает не всё подряд, а то, что реально ломает продукт. Иначе команда быстро привыкает к фону: одинаковые ошибки, дубль событий, тестовые окружения, локальные прогоны.

Базовый чек-лист настройки:
— разделите проекты по средам, а не сваливайте staging и production в один поток;
— отфильтруйте ошибки, которые уже пойманы обработчиком;
— отключите шум от ботов, health-check'ов и известных интеграций;
— задайте теги для релиза, окружения и пользователя, чтобы быстро искать паттерн.

Если алертят всё подряд, проблема почти всегда в одном из трёх мест: слишком широкий capture, нет ignore rules, или в коде бросают исключение там, где нужен контролируемый ответ. Sentry не чинит архитектуру, но очень быстро показывает, где у вас «ошибка» стала обычным сценарием.

Ещё одна типовая ошибка — смотреть только на stack trace. Полезнее сначала проверить частоту, окружение и путь пользователя до падения. Тогда один и тот же баг перестаёт выглядеть как десять разных инцидентов.

Держите Sentry как фильтр сигнала, а не как склад исключений: меньше мусора в потоке, быстрее triage, меньше ложных тревог.

Почему Resend часто берут вместо «просто SMTP» — и где на нём ломаются

Resend закрывает типичную боль: письма для продукта, а не для «почтового сервера в вакууме». У него удобный API, нормальная работа с шаблонами, webhooks по статусам и понятная интеграция в веб-приложение. Для транзакционных писем это обычно быстрее, чем поднимать свой SMTP-обвязку и потом разбираться с логами.

Но есть правило: сервис доставки не спасает плохую схему отправки. Если не настроены SPF, DKIM и домен-отправитель, письма будут попадать в спам или теряться. Второй частый промах — слать всё с одного адреса: отдельно держите парольные, уведомления и маркетинговые письма, иначе репутация домена смешается.

Ещё одна ошибка — не проверять idempotency и ретраи. При сбоях API письмо может уйти повторно, если приложение не защищено от дублей. И не забывайте про bounce/complaint события: без обработки webhooks список адресов быстро портится, а доставляемость падает 📩

Если нужен простой почтовый слой для продукта, Resend хорош как старт и как рабочая база. Но настройка домена, раздельные потоки писем и обработка статусов важнее самого провайдера.

Resend хорош не как «ещё один SMTP», а как быстрый слой для product email

Если у вас транзакционные письма, Resend обычно берут за три вещи: понятный API, нормальные шаблоны и минимум боли с интеграцией. Это удобно, когда письма нужны как часть продукта: регистрация, сброс пароля, уведомления, инвайты, чеки.

На практике смотреть стоит не на «фичи», а на операционку:
— есть ли отдельные домены и ключи под dev/stage/prod;
— как устроены webhooks и retry при сбоях;
— можно ли быстро проверить доставку, а не гадать по логам;
— насколько легко менять шаблоны без правок в бизнес-логике.

Слабое место почти у всех команд одно и то же: отправка письма прячется в коде слишком глубоко. Тогда любое изменение текста, темы или получателя превращается в мини-релиз. Нормальный подход — вынести письмо в отдельный сервисный слой, хранить шаблоны отдельно и логировать message id вместе с событием в приложении.

Ещё один важный фильтр — миграция с другого провайдера. Сначала проверьте, как переносится suppression list, как обрабатываются bounce/complaint и есть ли возможность параллельного прогона на тестовых доменах. Если этого нет, красивый API быстро превращается в дорогую точку отказа.

Итог простой: Resend имеет смысл там, где email — продуктовая функция, а не вспомогательная скрипт-рассылка. Перед выбором проверьте не маркетинг, а маршрут письма от триггера до inbox.

Vercel удобен, пока проект не начинает жить своей инфраструктурой

Vercel хорош для фронта, превью и быстрых деплоев: подключил репозиторий, получил build, preview и домен без лишней возни. Для лендингов, маркетинговых сайтов и Next.js-проектов это часто самый короткий путь до продакшена.

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

По деньгам логика простая: бесплатный слой годится для прототипа и малой нагрузки, а дальше платить приходится не за «сайт», а за удобство пайплайна, командную работу и трафик. Поэтому перед стартом полезно заранее проверить три вещи: где живёт state, кто обрабатывает async-задачи, и что будет при резком росте запросов. ⚙️

Если проект уже включает очереди, WebSocket, тяжёлую API-логику или много server-side вычислений, Vercel лучше считать витриной для фронта, а не местом, где держится вся система.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах?

История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения.

Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше.

Знаю многие кейсы, которые были в итоге решены благополучно до выхода в публичное поле и всегда приятно видеть, когда так происходит, но все больше и больше кейсов, которые не просто выходят в паблик, а еще и очень странным и глупым образом в паблике продолжают долго оставаться и наносить ущерб в то время как имеют очень простые и адекватные для обеих сторон варианты решения.

Вот например про один из таких кейсов писал уже здесь весной.

Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту.

Но когда одна сторона открыта к адекватной коммуникации и поиску оптимального решения, а вторая сторона просто игнорирует проблему, при этом не уходя с рынка в закат, а продолжая тратить огромные бюджеты на PR и маркетинг бренда - это любопытная аномалия.

Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал)

Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь.

Очень приличный на мой взгляд разбор со стороны и указание пары простых и логичных вариантов решения ситуации написал Артем Кравченко, можно почитать у него.

А я хочу разобрать эту историю с другой стороны, как можно оценивать репутационные потери от подобных историй непосредственно в деньгах и принимать более взвешенные решения, стоит ли вообще брендам занимать тактику игнорирования и допускать появление и продолжительное обмусоливание таких тем в паблике.

Для мелкого и крупного бренда такие истории могут иметь очень разный эффект, поэтому здесь разберем на примере крупного бренда, так как Melbet в нашем рынке относится именно к таким.

Не знаю конечно их точные цифры затрат на PR в рамках афф рынка (участие в конфах, собственные ивенты, реклама в афф медиа и т.п.), но из того, что вижу как организатор ивентов с приличным опытом, этот бюджет явно измеряется в миллионах $ в год, если не выходит за $10млн+.

Это без PR затрат на прямое привлечение игроков (бренд-амбассадоры, спонсорства футбольных клубов и т.п.), без бюджетов непосредственно на закупку трафика. Только на аффилейтку.

И вот уже более месяца в паблике незакрытый и не откоммуницированный публично кейс на $2k (две тысячи долларов).

В публичной дискуссии сейчас преобладает позиция, что Melbet в этом споре неправы.

Может их развернутая публичная позиция поменяла бы мнение, но ее нет, соответственно на данный момент так.

Какие материальные потери может понести бренд в такой истории?

Многие люди, даже очень опытные и умные, почему-то к таким ситуациям относятся бинарно.

Рухнет бренд (закроется, обанкротится) - значит плохо на них повлиял кейс.

Останется бренд жить и работать как ни в чем не бывало внешне - значит никак не повлияло и может они правильно решили игнорировать, а кто-то вообще решит брать с них пример.

Но это же совсем не так, ситуация не бинарная.

Представим не фактические цифры Melbet, которых у нас нет, а консервативную модель крупного рекламодателя.

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

Я не знаю внутренний LTV партнёра у Melbet. Но если принять для активного опытного аффилейта условные $10,000 LTV, десять таких потерянных партнеров - это уже шестизначная сумма $ недополученного дохода. И это без учёта крупных команд, в случае которых эффект может быть кратно выше и оказаться семизначным.

Даже если в этой модели ошибиться и завысить в несколько раз, сам принцип никуда не исчезает - незакрытый публичный спор на $2,000 в любом случае обойдется бренду многократно дороже этих $2,000.

Цифры конечно я прикинул условные, но рассуждения не виртуальные - я знаю афф команды, которые перестали быть их активными партнерами из-за этого кейса.

Одна известная в рынке команда публично рассказала о своем таком решении в моем чатике про scam-кейсы.

А теперь вернемся к миллионам долларов в год, которые Melbet тратит на публичный PR среди аффов через конфы и прочие активности.

У этих трат же есть определенные ожидаемые и реальные результаты, верно?

На каждый затраченный миллион ожидается определенное количество привлеченных новых партнеров и укрепление лояльности и увеличение оборотов с определенным количеством действующих партнеров.

Вообще без понятия какая там ожидаемая сумма выхлопа на каждый потраченный миллион, поэтому обозначим ожидаемую сумму выхлопа с потраченного на PR миллиона в X.

При таком незакрытом публичном кейсе, вызывающем большой отклик и возмущение в рынке - останется эта сумма выхлопа с PR X без учета прочих факторов или она станет меньше X?

Очевидно станет меньше, доверие к бренду ниже, а значит и вложения в PR дают меньшую отдачу.

Я понимаю, что не все читатели, в том числе заинтересованные, могут дружить с математикой, и особенно понятием математического ожидания на дистанции, но вопрос здесь не только в этике и не только в справедливости конкретной претензии. Это вопрос качества управленческого решения.

Когда бренд инвестирует миллионы в доверие рынка - через конференции, медиа, партнёрские активности и PR, игнорирование аргументированного публичного конфликта снижает отдачу от всех этих вложений. Репутация не выглядит отдельной строкой в P&L, но её потеря вполне превращается в недополученный доход, более дорогой PR и менее лояльных партнёров.

Я искренне надеюсь, что все больше компаний в нашем рынке будут становиться более сознательными и не терять огромные деньги на ровном месте, и если бизнес-этика не зашита в культурный код, то хотя бы из сугубо материальных корыстных соображений начнут вести себя адекватнее)

Всем отличной недели и благоразумия)