Cloudflare Workers ломают не код, а ожидания от серверной логики

Workers удобны там, где нужна быстрая edge-обработка: редиректы, A/B-маршрутизация, заголовки, кэш-правила, лёгкий API-слой. Но это не мини-Node.js. Если тащить внутрь тяжёлые библиотеки, файловую систему, долгие фоновые задачи или stateful-подход, получаются странные баги и лишние часы дебага.

За неделю в репах обычно всплывают одни и те же ошибки:
— надеются на полноценный runtime и не проверяют ограничения окружения;
— пишут бизнес-логику как в обычном backend, хотя лучше вынести её в API или очередь;
— забывают, что cold path должен быть коротким: парсинг, валидация, ответ;
— смешивают edge-логику с доступом к БД без кэша и таймаутов.

Если нужен Worker в проде, держите правило: он должен решать один маленький слой задачи. Всё, что требует длительных вычислений, сложных зависимостей или большой памяти, уводите наружу. А вот то, что выигрывает от географии и скорости ответа, оставляйте на edge. Для авторизации, прокси, шифрования токенов, шринка URL и маршрутизации это почти идеальная зона.

Есть наблюдение которое стоит проверить: чем меньше кода в Worker, тем проще миграции между сервисами и тем дешевле поддержка. Не потому что серверлесс магия, а потому что границы ответственности становятся очевидными.

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

Resend: когда email-сервис нужен не «на потом», а сразу в продукте

Resend обычно берут не ради «рассылок вообще», а чтобы быстро и чисто отправлять продуктовые письма: подтверждения, ресеты пароля, уведомления, инвойсы. Если у вас веб-приложение, это один из самых быстрых путей уйти от самописной SMTP-логики.

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

Для разработки важен не только API, но и то, как сервис встраивается в стек. Обычно хватает серверной функции, очереди и простой обёртки над отправкой. Если письмо критичное, добавляйте ретраи и логируйте request-id, иначе потом будете искать «куда делся reset».

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

Если выбираете email-сервис для продакшена, проверьте не маркетинг, а базу: доставляемость, webhooks, удобство шаблонов и то, как быстро вы восстановите отправку при сбое.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

🧠 Ещё больше инсайтов → в канале AFF.top

Pre-lander внутри WebView или прямой редирект: где теряется конверт и модерация

В связке WebView чаще выигрывает не «красивый» путь, а тот, где меньше лишних шагов между кликом и оффером. Прямой редирект хорош для простых воронок: пользователь быстро попал на страницу, меньше трения, проще считать. Но как только нужен прогрев, дисклеймер, локализация или обход жёсткой проверки, pre-lander внутри app-обёртки даёт больше контроля.

Что важно:
— Pre-lander внутри WebView полезен, когда нужно отсеять холодный трафик, собрать микрокоммит или показать промежуточный экран до оффера.
— Прямой редирект лучше, если креатив уже максимально «собран», а лишний экран только съедает CR.
— В WebView pre-lander должен грузиться быстро и не выглядеть как отдельный сайт с кучей внешних скриптов: это снижает риск флага.
— Если нужна цепочка из 2-3 шагов, чаще безопаснее делать её внутри одного контейнера, чем гонять пользователя по внешним доменам.

На практике: для теста всегда держите две версии — с pre-lander и без. Смотрите не только CR, но и глубину досмотра, отказ на первом экране, стабильность прохождения модерации. Иногда прямой редирект даёт лучший апрув по трафику, но хуже держит качество, а pre-lander наоборот режет объём, зато выравнивает лидов.

Если задача — быстрый CPA-сплит, начинайте с прямого редиректа; если нужен контроль пути и меньше сюрпризов от модерации, добавляйте pre-lander внутри WebView и не усложняйте цепочку без причины.

ISP-прокси vs residential: на каком этапе Facebook ловит траст

Residential нужен там, где Facebook смотрит на происхождение IP с подозрением. Регистрация аккаунта, первые три-четыре дня фарма, смена платёжки — всё это проходит мягче через IP реального абонента. Скорость и пинг здесь вторичны, важно нативное поведение сессии.

ISP-прокси берут, когда аккаунт уже прогрет и нужна стабильная труба для залива. Статический IP из дата-центра с residential-ASN даёт нормальную скорость загрузки крео и ровный пинг. Но на чистом антидетект-браузере с нуля такой IP часто получает дополнительную проверку или низкий стартовый траст.

На практике работает разделение: фарм и подготовка — на rotating residential, залив и скейл — на ISP из того же региона. Если переключать аккаунт с residential на ISP резко через разные города, сессия слетает. Переход должен быть в пределах одного региона и с сохранением сессионных кук.

Не гонитесь за одним типом под всё. Смотрите на стадию аккаунта: чем моложе акк, тем больше ему нужен residential. После двух недель стабильной истории смело ставьте ISP и лейте.

Sentry полезен только тогда, когда ошибки уже разложены по полкам, а не свалены в одну кучу

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

— Сразу задайте тегирование: environment, release, service, user segment.
— Группируйте ошибки по root cause, а не по тексту сообщения.
— Отсекайте ожидаемые фейлы: 404, отмены запросов, таймауты внешних API, если они не влияют на продукт.
— Для важного пути делайте отдельные alerts: логин, платежи, регистрация, фоновые джобы.

Полезная привычка — смотреть не на количество событий, а на повторяемость. Если ошибка всплывает редко, но ломает ключевой сценарий, ей нужен приоритет выше, чем у сотни пустых exception'ов. И наоборот: если одно и то же событие прилетает пачкой, сначала чините источник, потом настраивайте шумоподавление.

Sentry окупается не экраном красных иконок, а тем, что за 5 минут отвечает на три вопроса: где сломалось, у кого сломалось и как повторить. Если на них нет ответа — схема сбора настроена плохо.

Vercel ломается не в коде, а в мелочах вокруг деплоя

За неделю в репах чаще всего всплывают одни и те же ошибки: проект случайно завязан на локальные env, сборка требует файлов, которых нет в git, и preview-окружение ведёт себя не так, как production.

Проверка перед первым нормальным релизом простая:
— все переменные вынесены в env, без ручных правок на машине;
— билд проходит из чистого клона, а не только после «у меня локально работает»;
— папка output и кеши не требуют артефактов, которые не восстанавливаются на CI;
— роуты, редиректы и rewrite не завязаны на случайный порядок файлов.

Отдельно смотрите на serverless-логику: Vercel удобен для frontend-first проектов, но тяжёлые фоновые задачи, долгие запросы и stateful-части лучше сразу выносить в отдельный сервис. Иначе деградация проявляется не в падении, а в странных таймаутах и росте латентности.

Если проект растёт, полезно держать рядом правило: Vercel отвечает за delivery и edge, а всё, что пахнет очередями, cron и постоянным состоянием, должно жить отдельно. Так миграция не превращается в переписывание всей архитектуры.

Convex не заменяет базу данных: он убирает боль вокруг неё

Convex часто покупают с ожиданием “сейчас всё станет проще”. На деле он полезен там, где backend для продукта нужно собрать быстро, но без хаоса из ручных SQL-запросов, самописного realtime и вечной синхронизации состояния.

Сильная сторона Convex — не “магия”, а связка:
— данные, функции и подписки живут рядом;
— клиент получает обновления без отдельного слоя websockets;
— бизнес-логику проще держать в одном месте, чем размазывать по API, cron и очередям.

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

Ещё один полезный фильтр: Convex хорош, когда команда ценит скорость разработки выше тонкой настройки инфраструктуры. Если нужен полный контроль над БД, индексами, репликацией и экзотическими запросами — лучше сравнивать его не с “любым backend”, а с конкретным стеком, который вы уже умеете эксплуатировать.

Правило простое: берите Convex, если хотите быстрее собрать продуктовый backend без зоопарка сервисов. Не берите его как универсальную замену всего, что обычно называют “серверной частью”.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

Supabase ломают не на старте, а когда забывают про границы между app и DB

За неделю в репах: у Supabase чаще всего всплывают не «проблемы с Postgres», а архитектурные ошибки. Таблицы начинают обслуживать всё подряд: auth, бизнес-логику, файлы, фоновые задачи. Потом команда удивляется, почему миграции страшно трогать, а запросы разрастаются как монолит.

Есть наблюдение которое стоит проверить: если проект маленький, Supabase даёт быстрый старт. Но как только появляется несколько клиентов, роли, приватные данные и фоновые джобы, надо заранее разделять:
— что живёт в таблицах и RLS;
— что уходит в edge functions или backend;
— что нельзя отдавать в клиент вообще.
Иначе «удобный BaaS» превращается в набор скрытых зависимостей.

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

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

Railway: когда берут за быстрый деплой, а не за «идеальную» инфраструктуру

Railway удобно использовать там, где нужен рабочий backend без долгой возни с DevOps. Поднимаются API, воркеры, cron-задачи, PostgreSQL, Redis, фоновые джобы — всё в одной панели и с нормальным DX.

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

Что проверять до выбора:
— где будет жить база и насколько критична задержка
— нужен ли постоянный диск или хватит managed storage
— есть ли фоновые процессы, которые нельзя убивать при рестарте
— как сервис переживает пики по памяти и соединениям
— сможете ли вы потом уехать без боли в конфигурации

Railway часто выигрывает у ручного VPS именно скоростью старта: меньше скриптов, меньше nginx-магии, меньше «почему оно не поднялось после reboot». Но за эту простоту платят ограничениями архитектуры и меньшим контролем.

Если проект растёт, смотрите на Railway как на удобный стартовый слой. Если сразу нужен контроль над каждым узлом, лучше не путать комфорт с универсальностью.

Supabase ломается не на старте, а когда проекту нужен порядок в доступах и данных

За неделю в репах: Supabase чаще всего берут как быстрый backend «из коробки», а потом упираются в три вещи — права, миграции и границы free tier. База, auth, storage и edge-функции удобны, пока схема простая и команда не разрослась.

Проверь перед выбором:
— RLS включён сразу, иначе позже придётся переписывать доступы;
— миграции хранятся в репозитории, а не живут вручную в панели;
— отдельные env для local/stage/prod, чтобы не смешать тестовые данные с боевыми.

Есть наблюдение которое стоит проверить: Supabase хорошо подходит, когда нужен Postgres с быстрым стартом и минимальным DevOps. Но если у тебя сложные ACL, много фоновых задач или жёсткая изоляция по клиентам, заранее оцени, не упрёшься ли в архитектуру. В таких проектах «удобно сейчас» часто превращается в дорого «переделать потом».

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