Cloudflare Workers: когда edge ускоряет проект, а когда только усложняет стек
Workers берут на себя лёгкий backend на границе сети: редиректы, A/B-логика, проксирование, подпись запросов, простые API, валидацию и glue-код между сервисами. Для задач с коротким временем ответа это часто лучше, чем тащить отдельный сервер и держать его живым ради пары эндпоинтов.
Но есть типовой провал: в Workers пытаются запихнуть то, что требует долгих соединений, тяжёлого CPU, локального диска или сложного stateful-процесса. Там модель edge уже не помогает: код становится дороже в поддержке, а ограничения рантайма всплывают позже, чем нужно. Если логика похожа на полноценный backend — лучше сразу сравнивать с Fly.io, Railway или обычным сервером.
Перед миграцией проверь три вещи: 1) есть ли у кода зависимость от Node-only библиотек; 2) нужен ли доступ к файловой системе или фоновые задачи; 3) можно ли вынести состояние в KV, D1, Durable Objects или внешнюю БД. Если ответ «нет» хотя бы на один пункт — это не запрет, но сигнал оставить Workers только на тонком краю.
Ещё один полезный паттерн: держать Workers как слой маршрутизации и авторизации, а бизнес-логику — в отдельном сервисе. Тогда edge даёт быстрый первый ответ, а сложные операции живут там, где их проще тестировать и масштабировать.
Workers берут на себя лёгкий backend на границе сети: редиректы, A/B-логика, проксирование, подпись запросов, простые API, валидацию и glue-код между сервисами. Для задач с коротким временем ответа это часто лучше, чем тащить отдельный сервер и держать его живым ради пары эндпоинтов.
Но есть типовой провал: в Workers пытаются запихнуть то, что требует долгих соединений, тяжёлого CPU, локального диска или сложного stateful-процесса. Там модель edge уже не помогает: код становится дороже в поддержке, а ограничения рантайма всплывают позже, чем нужно. Если логика похожа на полноценный backend — лучше сразу сравнивать с Fly.io, Railway или обычным сервером.
Перед миграцией проверь три вещи: 1) есть ли у кода зависимость от Node-only библиотек; 2) нужен ли доступ к файловой системе или фоновые задачи; 3) можно ли вынести состояние в KV, D1, Durable Objects или внешнюю БД. Если ответ «нет» хотя бы на один пункт — это не запрет, но сигнал оставить Workers только на тонком краю.
Ещё один полезный паттерн: держать Workers как слой маршрутизации и авторизации, а бизнес-логику — в отдельном сервисе. Тогда edge даёт быстрый первый ответ, а сложные операции живут там, где их проще тестировать и масштабировать.
This media is not supported in your browser
VIEW IN TELEGRAM
Google заставляет махать руками перед камерой
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
Как заработать 2500$ с УБТ трафика из Twitter’а не привлекая внимания санитаров
Арбитражник проkил органическbq трафик с X (Twitter) через связку с dating-офферами, используя маскировку ссылок под видеопревью. После полугода залива с марта по октябрь 2025-го он заработал скромный, но стабильный доход, внедрив динамическую генерацию страниц, обфускацию ссылок и cookie-разделение трафика для увеличения конверсии на треть. Основной вызов — постоянные баны доменом из-за обновлений Google и требований антифрода, из…
➡️ Читайте на сайте: https://aff.top/blog/kak-zarabotat-2500-s-ubt-trafika-iz-twitter-a-ne-privlekaia-vnimaniia-sanitarov
🧠 Ещё больше инсайтов → в канале AFF.top
Арбитражник проkил органическbq трафик с X (Twitter) через связку с dating-офферами, используя маскировку ссылок под видеопревью. После полугода залива с марта по октябрь 2025-го он заработал скромный, но стабильный доход, внедрив динамическую генерацию страниц, обфускацию ссылок и cookie-разделение трафика для увеличения конверсии на треть. Основной вызов — постоянные баны доменом из-за обновлений Google и требований антифрода, из…
➡️ Читайте на сайте: https://aff.top/blog/kak-zarabotat-2500-s-ubt-trafika-iz-twitter-a-ne-privlekaia-vnimaniia-sanitarov
🧠 Ещё больше инсайтов → в канале AFF.top
Supabase берут как “готовый backend”, а ломаются обычно на схеме и правах доступа
Если смотреть на Supabase как на набор удобных кнопок, почти всегда вылезают одни и те же ошибки: таблицы делаются “на скорую руку”, доступы оставляют открытыми, а потом пытаются чинить это поверх продакшена.
За неделю в репах чаще всего всплывает такой паттерн:
— сначала делают auth и CRUD,
— потом добавляют хранение файлов и realtime,
— и только после этого вспоминают про ограничения, индексы и RLS.
Что проверять до первого запуска:
— таблицы и связи: не плодить дубли, сразу задать ключи и каскады;
— RLS: для каждой таблицы понять, кто читает и кто пишет;
— политики: не делать “разрешить всем”, если доступ нужен только владельцу;
— индексы: особенно на поля фильтрации и join;
— storage: отдельно продумать публичные и приватные файлы.
Есть наблюдение которое стоит проверить: Supabase удобно подходит там, где нужен быстрый старт и стандартный веб-стек, но плохо прощает хаос в модели данных. Если схема кривая, удобная оболочка только ускорит попадание в проблему.
Если проект может вырасти, лучше сразу описать роли, RLS и структуру таблиц на бумаге. Потом это дешевле, чем разбирать уже живой доступ к продакшену.
Если смотреть на Supabase как на набор удобных кнопок, почти всегда вылезают одни и те же ошибки: таблицы делаются “на скорую руку”, доступы оставляют открытыми, а потом пытаются чинить это поверх продакшена.
За неделю в репах чаще всего всплывает такой паттерн:
— сначала делают auth и CRUD,
— потом добавляют хранение файлов и realtime,
— и только после этого вспоминают про ограничения, индексы и RLS.
Что проверять до первого запуска:
— таблицы и связи: не плодить дубли, сразу задать ключи и каскады;
— RLS: для каждой таблицы понять, кто читает и кто пишет;
— политики: не делать “разрешить всем”, если доступ нужен только владельцу;
— индексы: особенно на поля фильтрации и join;
— storage: отдельно продумать публичные и приватные файлы.
Есть наблюдение которое стоит проверить: Supabase удобно подходит там, где нужен быстрый старт и стандартный веб-стек, но плохо прощает хаос в модели данных. Если схема кривая, удобная оболочка только ускорит попадание в проблему.
Если проект может вырасти, лучше сразу описать роли, RLS и структуру таблиц на бумаге. Потом это дешевле, чем разбирать уже живой доступ к продакшену.
Sentry ломают не баги, а шум: 6 настроек, которые чистят алерты
У большинства команд Sentry превращается в ленту тревог, где важное тонет в повторяющихся исключениях. Правильная настройка нужна не для «поймать всё», а чтобы видеть только то, что реально ломает пользовательский сценарий.
— Сначала разделите ошибки по окружениям: dev, staging, prod. Иначе тестовый мусор будет спорить с боевыми инцидентами.
— Включите фильтрацию known issues: старые баги должны уходить в архив, а не в ежедневный фон.
— Настройте игнор по браузерным расширениям, adblock и локальным экспериментам — это частый источник ложных срабатываний.
— Для frontend отдельно проверьте sourcemaps: без них стектрейсы выглядят красиво, но бесполезно.
Дальше смотрите на частоту и уникальность. Один и тот же TypeError, который падает тысячу раз, — это не тысяча задач, а один корневой дефект. Группируйте похожие события, режьте шум по release health и не отправляйте алерты на всё подряд: иначе команда быстро перестаёт им верить.
Ещё одна типовая ошибка — слать уведомления из каждого проекта в один канал без правил приоритета. Лучше оставить только критичные алерты, а остальное читать в интерфейсе по фильтрам и тегам. Так Sentry остаётся инструментом диагностики, а не генератором паники.
Если коротко: Sentry полезен только тогда, когда вы заранее договорились, какие ошибки считаются сигналом. Остальное должно молча ложиться в историю.
У большинства команд Sentry превращается в ленту тревог, где важное тонет в повторяющихся исключениях. Правильная настройка нужна не для «поймать всё», а чтобы видеть только то, что реально ломает пользовательский сценарий.
— Сначала разделите ошибки по окружениям: dev, staging, prod. Иначе тестовый мусор будет спорить с боевыми инцидентами.
— Включите фильтрацию known issues: старые баги должны уходить в архив, а не в ежедневный фон.
— Настройте игнор по браузерным расширениям, adblock и локальным экспериментам — это частый источник ложных срабатываний.
— Для frontend отдельно проверьте sourcemaps: без них стектрейсы выглядят красиво, но бесполезно.
Дальше смотрите на частоту и уникальность. Один и тот же TypeError, который падает тысячу раз, — это не тысяча задач, а один корневой дефект. Группируйте похожие события, режьте шум по release health и не отправляйте алерты на всё подряд: иначе команда быстро перестаёт им верить.
Ещё одна типовая ошибка — слать уведомления из каждого проекта в один канал без правил приоритета. Лучше оставить только критичные алерты, а остальное читать в интерфейсе по фильтрам и тегам. Так Sentry остаётся инструментом диагностики, а не генератором паники.
Если коротко: Sentry полезен только тогда, когда вы заранее договорились, какие ошибки считаются сигналом. Остальное должно молча ложиться в историю.
Dev SaaS выгоден не “по ощущениям”, а когда вы считаете 4 вещи до подписки
За неделю в репах: половина проблем с подписками возникает не в коде, а в ожиданиях. Сервис берут “на попробовать”, а потом выясняется, что free tier не закрывает реальную нагрузку, а платный план нужен не для фич, а ради лимитов.
Перед подключением проверьте:
— Лимиты: запросы, проекты, seats, retention, storage, webhooks. Самый частый сюрприз — скрытый потолок в месте, где уже завязана логика.
— Модель оплаты: за пользователя, за usage, за инстанс, за событие. Для агентства и продукта это разные риски.
— Миграцию: есть ли экспорт, как забрать данные, можно ли пережить откат без ручной чистки.
— Vendor lock-in: что ломается, если сервис исчезает из стека через полгода.
Есть наблюдение которое стоит проверить: дорогим сервис становится не из-за цены, а из-за отсутствия плана замены. Если в архитектуре нет резервного пути, любая интеграция превращается в долгий долг.
Для Sentry, Vercel, Supabase, Railway, Neon и похожих сервисов правило одно: сначала считайте границы, потом встраивайте в критичный путь. Так подписка остаётся инструментом, а не точкой зависимости.
За неделю в репах: половина проблем с подписками возникает не в коде, а в ожиданиях. Сервис берут “на попробовать”, а потом выясняется, что free tier не закрывает реальную нагрузку, а платный план нужен не для фич, а ради лимитов.
Перед подключением проверьте:
— Лимиты: запросы, проекты, seats, retention, storage, webhooks. Самый частый сюрприз — скрытый потолок в месте, где уже завязана логика.
— Модель оплаты: за пользователя, за usage, за инстанс, за событие. Для агентства и продукта это разные риски.
— Миграцию: есть ли экспорт, как забрать данные, можно ли пережить откат без ручной чистки.
— Vendor lock-in: что ломается, если сервис исчезает из стека через полгода.
Есть наблюдение которое стоит проверить: дорогим сервис становится не из-за цены, а из-за отсутствия плана замены. Если в архитектуре нет резервного пути, любая интеграция превращается в долгий долг.
Для Sentry, Vercel, Supabase, Railway, Neon и похожих сервисов правило одно: сначала считайте границы, потом встраивайте в критичный путь. Так подписка остаётся инструментом, а не точкой зависимости.
Drupal берут не за «простоту»: 5 причин, когда он окупается лучше лёгких CMS
Drupal обычно выбирают не потому, что он удобный на старте, а потому что он не разваливается на сложной структуре контента. Если у проекта много типов материалов, ролей, связей между сущностями и правил публикации, у него меньше шансов стать набором костылей.
— Нужны сложные редакторские сценарии: разные формы для разных ролей, модерация, ревью, черновики, ограничения по полям.
— Контент не плоский: статьи, карточки, авторы, теги, регионы, каталоги, связанные сущности.
— Требуется жёсткая логика доступа: кто видит, кто правит, кто публикует, кто экспортирует.
— Проект живёт долго: важнее архитектура и сопровождение, чем быстрый старт на шаблоне.
— Есть команда, которая умеет держать дисциплину в структуре, а не лечить хаос плагинами.
Слабое место Drupal тоже понятное: если задача — простой лендинг или сайт-визитка, он часто избыточен. Там, где нужен только быстрый запуск и минимум сущностей, его мощность превращается в лишнюю сложность.
Есть наблюдение которое стоит проверить: Drupal особенно хорошо работает там, где контент уже начал «расти в стороны». Если вы заранее видите каталоги, фильтры, права, многоязычность и интеграции, лучше считать его не тяжёлой CMS, а платформой управления структурой.
Если сомневаетесь, задайте себе один вопрос: проекту нужна страница или модель данных? В первом случае Drupal почти наверняка лишний. Во втором — может оказаться самым дешёвым по сопровождению.
Drupal обычно выбирают не потому, что он удобный на старте, а потому что он не разваливается на сложной структуре контента. Если у проекта много типов материалов, ролей, связей между сущностями и правил публикации, у него меньше шансов стать набором костылей.
— Нужны сложные редакторские сценарии: разные формы для разных ролей, модерация, ревью, черновики, ограничения по полям.
— Контент не плоский: статьи, карточки, авторы, теги, регионы, каталоги, связанные сущности.
— Требуется жёсткая логика доступа: кто видит, кто правит, кто публикует, кто экспортирует.
— Проект живёт долго: важнее архитектура и сопровождение, чем быстрый старт на шаблоне.
— Есть команда, которая умеет держать дисциплину в структуре, а не лечить хаос плагинами.
Слабое место Drupal тоже понятное: если задача — простой лендинг или сайт-визитка, он часто избыточен. Там, где нужен только быстрый запуск и минимум сущностей, его мощность превращается в лишнюю сложность.
Есть наблюдение которое стоит проверить: Drupal особенно хорошо работает там, где контент уже начал «расти в стороны». Если вы заранее видите каталоги, фильтры, права, многоязычность и интеграции, лучше считать его не тяжёлой CMS, а платформой управления структурой.
Если сомневаетесь, задайте себе один вопрос: проекту нужна страница или модель данных? В первом случае Drupal почти наверняка лишний. Во втором — может оказаться самым дешёвым по сопровождению.
Convex берут не ради «ещё одного бэкенда», а ради скорости сборки realtime-приложений
Convex — это backend-as-a-service, где запросы, мутации и подписки живут в одной модели. Для чата, дашборда, CRM, таск-трекера или админки это снимает три типовые боли: ручную синхронизацию состояния, отдельный слой websockets и вечную возню с REST-эндпоинтами.
Что обычно радует вживую:
— данные сразу доступны через типизированные запросы;
— realtime обновления подключаются без лишней инфраструктуры;
— серверная логика пишется ближе к привычному JS/TS-стеку.
Но есть и обратная сторона: если проекту нужен сложный SQL, нестандартные отчёты или тяжёлая аналитика, Convex легко становится удобным, но тесным домом.
Есть наблюдение которое стоит проверить: Convex хорошо заходит там, где продукт растёт через частые мелкие изменения данных. Если у вас много «кто-то что-то поменял — всем это надо увидеть сразу», он экономит часы на сборке glue-кода. Если же ядро проекта — сложные выборки, миграции и BI, лучше заранее считать стоимость будущего переезда.
Практика простая: держите в Convex слой для транзакционной логики и realtime, а аналитику, большие выборки и тяжёлые джобы сразу планируйте отдельно. Тогда сервис даёт скорость без ощущения, что вы строите приложение в коробке без выхода.
Convex — это backend-as-a-service, где запросы, мутации и подписки живут в одной модели. Для чата, дашборда, CRM, таск-трекера или админки это снимает три типовые боли: ручную синхронизацию состояния, отдельный слой websockets и вечную возню с REST-эндпоинтами.
Что обычно радует вживую:
— данные сразу доступны через типизированные запросы;
— realtime обновления подключаются без лишней инфраструктуры;
— серверная логика пишется ближе к привычному JS/TS-стеку.
Но есть и обратная сторона: если проекту нужен сложный SQL, нестандартные отчёты или тяжёлая аналитика, Convex легко становится удобным, но тесным домом.
Есть наблюдение которое стоит проверить: Convex хорошо заходит там, где продукт растёт через частые мелкие изменения данных. Если у вас много «кто-то что-то поменял — всем это надо увидеть сразу», он экономит часы на сборке glue-кода. Если же ядро проекта — сложные выборки, миграции и BI, лучше заранее считать стоимость будущего переезда.
Практика простая: держите в Convex слой для транзакционной логики и realtime, а аналитику, большие выборки и тяжёлые джобы сразу планируйте отдельно. Тогда сервис даёт скорость без ощущения, что вы строите приложение в коробке без выхода.
Supabase удобно брать как backend, но ошибку обычно делают в схеме и правах
Supabase часто воспринимают как «Postgres с auth и storage», а потом проект начинает тормозить не из-за сервиса, а из-за архитектуры. Самая частая проблема — тащить в него всё подряд: бизнес-логику, фоновые задачи, сложные выборки, realtime и публичный API без границ.
За неделю в репах: рабочий паттерн такой —
— Postgres оставляют для данных и транзакций
— Auth используют только для идентификации
— Storage — для файлов, а не как CDN
— Edge Functions — для тонкой обвязки, а не для тяжелых вычислений
Дальше включается дисциплина по доступам. Если в проекте смешаны публичные и приватные таблицы, RLS надо проектировать сразу, а не «потом дописать». Иначе одна удобная политика превращается в дыру, которую сложно закрыть без миграций и переписывания клиента.
Еще один типовой промах — хранить в Supabase то, что лучше вынести наружу: очереди, долгие джобы, агрегации по большим таблицам, аналитические события без фильтров. Для этого у сервиса хорошие инструменты старта, но не бесконечный запас ресурса.
Если брать Supabase в прод, держите простое правило: схема, политики и границы ответственности важнее, чем «быстро поднять MVP». Тогда миграция и рост проекта будут гораздо дешевле.
Supabase часто воспринимают как «Postgres с auth и storage», а потом проект начинает тормозить не из-за сервиса, а из-за архитектуры. Самая частая проблема — тащить в него всё подряд: бизнес-логику, фоновые задачи, сложные выборки, realtime и публичный API без границ.
За неделю в репах: рабочий паттерн такой —
— Postgres оставляют для данных и транзакций
— Auth используют только для идентификации
— Storage — для файлов, а не как CDN
— Edge Functions — для тонкой обвязки, а не для тяжелых вычислений
Дальше включается дисциплина по доступам. Если в проекте смешаны публичные и приватные таблицы, RLS надо проектировать сразу, а не «потом дописать». Иначе одна удобная политика превращается в дыру, которую сложно закрыть без миграций и переписывания клиента.
Еще один типовой промах — хранить в Supabase то, что лучше вынести наружу: очереди, долгие джобы, агрегации по большим таблицам, аналитические события без фильтров. Для этого у сервиса хорошие инструменты старта, но не бесконечный запас ресурса.
Если брать Supabase в прод, держите простое правило: схема, политики и границы ответственности важнее, чем «быстро поднять MVP». Тогда миграция и рост проекта будут гораздо дешевле.
Cloudflare Workers: когда edge дешевле сервера, а когда превращается в лишнюю сложность
Workers хороши не как «ещё один VPS», а как способ вынести короткую логику ближе к пользователю: редиректы, подпись URL, авторизацию, прокси к API, легкий BFF. Там, где запрос должен жить миллисекунды и не хранить состояние, edge обычно выигрывает по простоте доставки.
Но есть типичные ошибки. — тащить в Workers тяжёлую бизнес-логику с долгими зависимостями; — ждать от них обычного сервера с фоновыми задачами; — хранить сессию в памяти; — забывать, что холодный старт и лимиты по времени/CPU ломают «вечные» обработчики. Если нужна очередь, cron, полноценный stateful backend — это уже не их зона.
Отдельно проверьте интеграции: WebSocket, большие upload/download, бинарные ответы, заголовки кэша и поведение fetch-переадресаций. Именно тут появляются баги, которые в локальной сборке не видно, а в проде они выглядят как «иногда не работает» ⚙️
Хорошее правило простое: если функцию можно описать как «принять запрос, быстро решить, вернуть ответ» — Worker подходит; если нужен долгий процесс, общий контекст или много побочных эффектов — берите другой слой.
Workers хороши не как «ещё один VPS», а как способ вынести короткую логику ближе к пользователю: редиректы, подпись URL, авторизацию, прокси к API, легкий BFF. Там, где запрос должен жить миллисекунды и не хранить состояние, edge обычно выигрывает по простоте доставки.
Но есть типичные ошибки. — тащить в Workers тяжёлую бизнес-логику с долгими зависимостями; — ждать от них обычного сервера с фоновыми задачами; — хранить сессию в памяти; — забывать, что холодный старт и лимиты по времени/CPU ломают «вечные» обработчики. Если нужна очередь, cron, полноценный stateful backend — это уже не их зона.
Отдельно проверьте интеграции: WebSocket, большие upload/download, бинарные ответы, заголовки кэша и поведение fetch-переадресаций. Именно тут появляются баги, которые в локальной сборке не видно, а в проде они выглядят как «иногда не работает» ⚙️
Хорошее правило простое: если функцию можно описать как «принять запрос, быстро решить, вернуть ответ» — Worker подходит; если нужен долгий процесс, общий контекст или много побочных эффектов — берите другой слой.
PlanetScale хорош, пока вы не упёрлись в миграции и разъезд схемы
У PlanetScale сильная сторона — безопасная работа с MySQL-подобной базой без привычного страха сломать прод. Но у этого удобства есть цена: часть сценариев с жёсткими foreign key, сложными транзакциями и ручным контролем схемы приходится перестраивать.
На что смотреть до старта:
— есть ли у вас зависимость от foreign key на уровне приложения;
— умеет ли команда жить без «одной большой миграции в прод»;
— готовы ли вы разнести запись и аналитику по разным слоям;
— не нужен ли вам полный контроль над поведением сервера и расширениями.
Сильный сценарий для PlanetScale — когда схема меняется часто, а выкатывать нужно без блокировок и простоев. Плохой сценарий — классический монолит с плотными связями между таблицами, где миграции и связи базы сами держат логику домена.
Перед переносом полезно прогнать один тест: можно ли удалить foreign key из базы и не сломать целостность в коде. Если ответ «нет», миграция в PlanetScale почти наверняка станет не технической, а архитектурной задачей.
Хорошее правило простое: сначала проверьте модель данных, потом цену и только потом делайте выбор.
У PlanetScale сильная сторона — безопасная работа с MySQL-подобной базой без привычного страха сломать прод. Но у этого удобства есть цена: часть сценариев с жёсткими foreign key, сложными транзакциями и ручным контролем схемы приходится перестраивать.
На что смотреть до старта:
— есть ли у вас зависимость от foreign key на уровне приложения;
— умеет ли команда жить без «одной большой миграции в прод»;
— готовы ли вы разнести запись и аналитику по разным слоям;
— не нужен ли вам полный контроль над поведением сервера и расширениями.
Сильный сценарий для PlanetScale — когда схема меняется часто, а выкатывать нужно без блокировок и простоев. Плохой сценарий — классический монолит с плотными связями между таблицами, где миграции и связи базы сами держат логику домена.
Перед переносом полезно прогнать один тест: можно ли удалить foreign key из базы и не сломать целостность в коде. Если ответ «нет», миграция в PlanetScale почти наверняка станет не технической, а архитектурной задачей.
Хорошее правило простое: сначала проверьте модель данных, потом цену и только потом делайте выбор.
PlanetScale берут не за “мощность”, а за то, как он снимает боль с MySQL-схемы
Если у вас продукт на MySQL и каждое изменение таблицы превращается в мини-релиз, PlanetScale полезен не как “ещё одна база”, а как слой безопасных изменений. Главная идея — работать через ветки схемы: проверяете миграцию отдельно, а потом аккуратно вносите её в боевую базу.
Что обычно выигрывают:
— меньше страха перед ALTER TABLE и долгими блокировками;
— проще катить изменения вместе с кодом;
— удобно, когда над схемой работает не один человек, а команда;
— легче тестировать backfill и переходы между структурами.
Но есть и ограничения. Если вам нужны жёсткие foreign key, сложная транзакционная логика на уровне схемы или вы строите систему, где MySQL используется как “всё и сразу”, PlanetScale может оказаться слишком opinionated. Его сильная сторона — дисциплина изменений, а не попытка заменить любую реляционную БД.
Ещё один полезный паттерн: держать приложение готовым к двум версиям схемы одновременно. Тогда миграции перестают быть ночным ритуалом, а становятся обычной операцией.
Если ваша боль — не запросы, а именно миграции и страх сломать прод, PlanetScale стоит оценивать первым.
Если у вас продукт на MySQL и каждое изменение таблицы превращается в мини-релиз, PlanetScale полезен не как “ещё одна база”, а как слой безопасных изменений. Главная идея — работать через ветки схемы: проверяете миграцию отдельно, а потом аккуратно вносите её в боевую базу.
Что обычно выигрывают:
— меньше страха перед ALTER TABLE и долгими блокировками;
— проще катить изменения вместе с кодом;
— удобно, когда над схемой работает не один человек, а команда;
— легче тестировать backfill и переходы между структурами.
Но есть и ограничения. Если вам нужны жёсткие foreign key, сложная транзакционная логика на уровне схемы или вы строите систему, где MySQL используется как “всё и сразу”, PlanetScale может оказаться слишком opinionated. Его сильная сторона — дисциплина изменений, а не попытка заменить любую реляционную БД.
Ещё один полезный паттерн: держать приложение готовым к двум версиям схемы одновременно. Тогда миграции перестают быть ночным ритуалом, а становятся обычной операцией.
Если ваша боль — не запросы, а именно миграции и страх сломать прод, PlanetScale стоит оценивать первым.
Supabase часто ломают не в коде, а в схеме доступа и типах
Если вы используете Supabase как «Postgres с удобным API», главный риск — начать доверять клиенту слишком много. База остаётся обычной реляционной, а значит ошибки в RLS, индексах и миграциях бьют по продакшену сильнее, чем баг в UI.
За неделю в репах: чаще всего всплывают три вещи:
— политики RLS написаны «на глаз» и либо открывают лишнее, либо режут рабочие запросы;
— типы в `select` и `insert` расходятся с реальной схемой, особенно после ручных правок;
— тяжёлые запросы идут без индексов под фильтр и сортировку, потому что локально всё «и так быстро».
Хорошая привычка — держать схему как код:
— миграции только через SQL-файлы;
— отдельная проверка на права доступа для публичных таблиц;
— для каждого критичного запроса смотреть `EXPLAIN`, а не надеяться на магию клиента.
Ещё один частый провал — хранить логику, которую проще вынести в серверную функцию, прямо в фронтенде. Как только появляются админские роли, фоновые операции или сложная валидация, клиентский доступ перестаёт быть удобством и становится риском.
Если строите на Supabase продукт, сначала зафиксируйте границы доступа и индексы, и только потом масштабируйте фичи. Именно это потом экономит недели отладки.
Если вы используете Supabase как «Postgres с удобным API», главный риск — начать доверять клиенту слишком много. База остаётся обычной реляционной, а значит ошибки в RLS, индексах и миграциях бьют по продакшену сильнее, чем баг в UI.
За неделю в репах: чаще всего всплывают три вещи:
— политики RLS написаны «на глаз» и либо открывают лишнее, либо режут рабочие запросы;
— типы в `select` и `insert` расходятся с реальной схемой, особенно после ручных правок;
— тяжёлые запросы идут без индексов под фильтр и сортировку, потому что локально всё «и так быстро».
Хорошая привычка — держать схему как код:
— миграции только через SQL-файлы;
— отдельная проверка на права доступа для публичных таблиц;
— для каждого критичного запроса смотреть `EXPLAIN`, а не надеяться на магию клиента.
Ещё один частый провал — хранить логику, которую проще вынести в серверную функцию, прямо в фронтенде. Как только появляются админские роли, фоновые операции или сложная валидация, клиентский доступ перестаёт быть удобством и становится риском.
Если строите на Supabase продукт, сначала зафиксируйте границы доступа и индексы, и только потом масштабируйте фичи. Именно это потом экономит недели отладки.
5 битрикс-ошибок, которые ломают сайт не сразу, а в самый неудобный момент
На 1С-Битрикс чаще всего падают не «сложные» места, а базовые мелочи в сборке и поддержке. Они долго живут тихо, а потом вылезают в проде: после переноса, обновления, чистки кеша или смены домена.
— Смешивают логику шаблона и бизнес-логику. Когда в
— Правят ядро вместо расширения. Любая правка в системных файлах потом мешает обновлению и делает баги невоспроизводимыми. Если нужно изменить поведение — ищите событие, обработчик или наследование.
— Игнорируют кеш. На Битриксе проблема часто не в коде, а в том, что страница продолжает отдавать старый результат. После правок проверяйте не только файл, но и тегированный кеш, композит и сторонние кеширующие слои.
— Не проверяют права и типы данных. Пустой массив, строка вместо числа, лишний доступ у пользователя — и компонент начинает вести себя непредсказуемо. Простая валидация на входе экономит часы поиска.
— Деплоят без сценария отката. Если после переноса нет понятного способа вернуть файлы, базу и кеш в исходное состояние, любая ошибка превращается в простой. Для агентского проекта это уже не «мелочь», а риск.
Дисциплина здесь важнее героизма: не трогать ядро, не смешивать слои, проверять кеш и всегда иметь план отката. На Битриксе это работает лучше любых срочных правок.
На 1С-Битрикс чаще всего падают не «сложные» места, а базовые мелочи в сборке и поддержке. Они долго живут тихо, а потом вылезают в проде: после переноса, обновления, чистки кеша или смены домена.
— Смешивают логику шаблона и бизнес-логику. Когда в
header.php и компонентах лежат запросы, условия и правки данных, отладка превращается в квест. Держите вывод отдельно, обработку — в своих классах или include-файлах.— Правят ядро вместо расширения. Любая правка в системных файлах потом мешает обновлению и делает баги невоспроизводимыми. Если нужно изменить поведение — ищите событие, обработчик или наследование.
— Игнорируют кеш. На Битриксе проблема часто не в коде, а в том, что страница продолжает отдавать старый результат. После правок проверяйте не только файл, но и тегированный кеш, композит и сторонние кеширующие слои.
— Не проверяют права и типы данных. Пустой массив, строка вместо числа, лишний доступ у пользователя — и компонент начинает вести себя непредсказуемо. Простая валидация на входе экономит часы поиска.
— Деплоят без сценария отката. Если после переноса нет понятного способа вернуть файлы, базу и кеш в исходное состояние, любая ошибка превращается в простой. Для агентского проекта это уже не «мелочь», а риск.
Дисциплина здесь важнее героизма: не трогать ядро, не смешивать слои, проверять кеш и всегда иметь план отката. На Битриксе это работает лучше любых срочных правок.
This media is not supported in your browser
VIEW IN TELEGRAM
Как уходят из арбитража трафика: интервью с бывшим медиабайером
Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…
➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom
🧠 Ещё больше инсайтов → в канале AFF.top
Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…
➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom
🧠 Ещё больше инсайтов → в канале AFF.top
Elementor ломает скорость не сам по себе, а через 5 типовых ошибок в сборке
За неделю в репах: почти каждый «тяжёлый» лендинг на Elementor страдает от одного и того же — слишком много секций, дублирующих виджетов и лишних обёрток. Это не проблема «конструктора вообще», а следствие того, как собирают страницу: один блок ради отступа, второй ради фона, третий ради адаптива.
Проверь базу:
— не ставь лишние inner section, если хватит одного контейнера;
— не используй глобальные стили точечно в каждом виджете;
— не плодить анимации и параллакс без причины;
— не вешай тяжёлые иконки/шрифты там, где хватит SVG;
— не тащи на страницу всё, что есть в библиотеке, если нужен один экран.
Есть наблюдение которое стоит проверить: чаще всего тормозит не сам первый экран, а хвост из слайдеров, табов, форм и карточек ниже. Именно там накапливаются DOM-узлы, лишний CSS и JS, из-за которых падают Core Web Vitals и растёт время до интерактива.
Если Elementor нужен в коммерческом проекте, держи правило: каждый новый виджет должен отвечать на вопрос «он ускоряет продажу или только усложняет рендер?». Если ответа нет — удаляй или заменяй на более простой блок.
За неделю в репах: почти каждый «тяжёлый» лендинг на Elementor страдает от одного и того же — слишком много секций, дублирующих виджетов и лишних обёрток. Это не проблема «конструктора вообще», а следствие того, как собирают страницу: один блок ради отступа, второй ради фона, третий ради адаптива.
Проверь базу:
— не ставь лишние inner section, если хватит одного контейнера;
— не используй глобальные стили точечно в каждом виджете;
— не плодить анимации и параллакс без причины;
— не вешай тяжёлые иконки/шрифты там, где хватит SVG;
— не тащи на страницу всё, что есть в библиотеке, если нужен один экран.
Есть наблюдение которое стоит проверить: чаще всего тормозит не сам первый экран, а хвост из слайдеров, табов, форм и карточек ниже. Именно там накапливаются DOM-узлы, лишний CSS и JS, из-за которых падают Core Web Vitals и растёт время до интерактива.
Если Elementor нужен в коммерческом проекте, держи правило: каждый новый виджет должен отвечать на вопрос «он ускоряет продажу или только усложняет рендер?». Если ответа нет — удаляй или заменяй на более простой блок.
7 ошибок в TypeScript, которые тихо ломают типы и замедляют рефакторинг
— Слишком широко заданные типы: string вместо конкретных литералов, any вместо unknown, объект без явных полей. В итоге IDE перестаёт подсказывать полезное, а ошибки уезжают в рантайм.
— Игнорирование strict и соседних флагов. Когда проверки выключены, типы выглядят «рабочими», но не защищают от null, undefined и несовместимых вызовов.
— Злоупотребление type assertion. Запись вида as SomeType не чинит данные, она только заставляет компилятор поверить на слово.
Ещё одна частая проблема — дублирование ручных интерфейсов там, где достаточно infer, keyof и mapped types. Чем больше копипаста между DTO, формами и API-ответами, тем дороже любой rename. Отдельно смотрите на union-типы без дискриминатора: потом их приходится распаковывать цепочками if и проверками на наличие полей.
Хороший стиль в TypeScript — это не «пожёстче типы», а меньше мест, где компилятор может ошибиться вместе с вами.
Если в репе типы начали мешать быстрее, чем помогать, начните с двух вещей: включите строгие проверки и уберите самые опасные as.
— Слишком широко заданные типы: string вместо конкретных литералов, any вместо unknown, объект без явных полей. В итоге IDE перестаёт подсказывать полезное, а ошибки уезжают в рантайм.
— Игнорирование strict и соседних флагов. Когда проверки выключены, типы выглядят «рабочими», но не защищают от null, undefined и несовместимых вызовов.
— Злоупотребление type assertion. Запись вида as SomeType не чинит данные, она только заставляет компилятор поверить на слово.
Ещё одна частая проблема — дублирование ручных интерфейсов там, где достаточно infer, keyof и mapped types. Чем больше копипаста между DTO, формами и API-ответами, тем дороже любой rename. Отдельно смотрите на union-типы без дискриминатора: потом их приходится распаковывать цепочками if и проверками на наличие полей.
Хороший стиль в TypeScript — это не «пожёстче типы», а меньше мест, где компилятор может ошибиться вместе с вами.
Если в репе типы начали мешать быстрее, чем помогать, начните с двух вещей: включите строгие проверки и уберите самые опасные as.
Railway удобен до первой миграции: где прячется настоящая цена простоты
Railway любят за быстрый старт: репозиторий, переменные, деплой, база рядом. Но для веб-проекта важнее не «запустилось за 5 минут», а что будет через 3–6 месяцев, когда появятся фоновые задачи, несколько окружений и рост трафика.
Что проверять до входа:
— как считаются ресурсы: CPU, RAM, простои, сеть
— есть ли у каждого сервиса отдельная цена за релоад и хранение
— можно ли без боли вынести Postgres, Redis и воркеры в разные места
— как устроены бэкапы, restore и ручной экспорт
Слабое место Railway — не сам хостинг, а иллюзия монолита. Пока всё в одном проекте, удобно. Потом начинаются скрытые зависимости: web ждёт очередь, очередь ждёт БД, БД упирается в лимиты, а перенос одного компонента тянет за собой весь стек. Для агентств и соло-разработчиков это особенно заметно: скорость старта высокая, цена ошибки тоже.
Если строите MVP — Railway нормален. Если уже есть SLA, фоновые джобы и несколько сред, заранее держите план выхода: где будет база, куда переедут воркеры, чем замените внутренние связки. Иначе самая дешёвая неделя разработки легко превращается в дорогую миграцию.
Railway любят за быстрый старт: репозиторий, переменные, деплой, база рядом. Но для веб-проекта важнее не «запустилось за 5 минут», а что будет через 3–6 месяцев, когда появятся фоновые задачи, несколько окружений и рост трафика.
Что проверять до входа:
— как считаются ресурсы: CPU, RAM, простои, сеть
— есть ли у каждого сервиса отдельная цена за релоад и хранение
— можно ли без боли вынести Postgres, Redis и воркеры в разные места
— как устроены бэкапы, restore и ручной экспорт
Слабое место Railway — не сам хостинг, а иллюзия монолита. Пока всё в одном проекте, удобно. Потом начинаются скрытые зависимости: web ждёт очередь, очередь ждёт БД, БД упирается в лимиты, а перенос одного компонента тянет за собой весь стек. Для агентств и соло-разработчиков это особенно заметно: скорость старта высокая, цена ошибки тоже.
Если строите MVP — Railway нормален. Если уже есть SLA, фоновые джобы и несколько сред, заранее держите план выхода: где будет база, куда переедут воркеры, чем замените внутренние связки. Иначе самая дешёвая неделя разработки легко превращается в дорогую миграцию.
Vercel CLI уходит от Node.js: native binary уже доступен в эксперименте
Vercel выкатил optional experimental native binary для CLI.
Он стартует быстрее, не требует Node.js runtime, а бинарники подписаны кодом — ОС может проверить, что их не подменяли. На macOS креды кладутся в system Keychain, scoped to the binary.
Для команд, которые живут на Vercel и рядом с ним, это не косметика.
Меньше внешних зависимостей в тулчейне, проще раскатка на macOS/Linux/Windows x64 и arm64.
Если у вас CI, локальные скрипты или internal tooling завязаны на
Интересно будет посмотреть, как быстро это перестанет быть “experimental”.
Vercel выкатил optional experimental native binary для CLI.
Он стартует быстрее, не требует Node.js runtime, а бинарники подписаны кодом — ОС может проверить, что их не подменяли. На macOS креды кладутся в system Keychain, scoped to the binary.
Для команд, которые живут на Vercel и рядом с ним, это не косметика.
Меньше внешних зависимостей в тулчейне, проще раскатка на macOS/Linux/Windows x64 и arm64.
Если у вас CI, локальные скрипты или internal tooling завязаны на
vercel и vc, это уже повод прогнать бинарник в тестовой среде и сравнить поведение с текущим CLI.Интересно будет посмотреть, как быстро это перестанет быть “experimental”.
Resend ломается не на отправке, а на плохой модели писем и доменов
Если используете Resend как «просто SMTP для транзакционки», проблемы обычно приходят не в API, а в структуре почты. Сначала настройте отдельный домен или поддомен под отправку: так проще разводить продуктовые письма, маркетинг и внутренние уведомления.
Дальше проверьте базу:
— SPF, DKIM и DMARC должны быть согласованы, иначе доставляемость будет плавать
— From-адрес должен быть стабильным, без случайных смен между сервисами
— Reply-To лучше задавать отдельно, если ответы не должны падать в общий ящик
Вторая типовая ошибка — слать всё из одного канала. Транзакционные письма, OTP, инвойсы и дайджесты лучше разделять по типам, шаблонам и даже по доменам отправки. Тогда сбой в одном сценарии не уронит доверие ко всем остальным.
Третье — шаблоны. Не делайте письмо «картинкой с кнопкой»: держите текстовую часть, понятную тему, короткий preheader и один главный CTA. Для писем с кодами и уведомлениями это важнее любой верстки.
Если нужен быстрый чек: домен, аутентификация, разделение потоков, шаблоны, логирование ошибок доставки. На этом Resend начинает работать как инфраструктура, а не как просто кнопка Send.
Если используете Resend как «просто SMTP для транзакционки», проблемы обычно приходят не в API, а в структуре почты. Сначала настройте отдельный домен или поддомен под отправку: так проще разводить продуктовые письма, маркетинг и внутренние уведомления.
Дальше проверьте базу:
— SPF, DKIM и DMARC должны быть согласованы, иначе доставляемость будет плавать
— From-адрес должен быть стабильным, без случайных смен между сервисами
— Reply-To лучше задавать отдельно, если ответы не должны падать в общий ящик
Вторая типовая ошибка — слать всё из одного канала. Транзакционные письма, OTP, инвойсы и дайджесты лучше разделять по типам, шаблонам и даже по доменам отправки. Тогда сбой в одном сценарии не уронит доверие ко всем остальным.
Третье — шаблоны. Не делайте письмо «картинкой с кнопкой»: держите текстовую часть, понятную тему, короткий preheader и один главный CTA. Для писем с кодами и уведомлениями это важнее любой верстки.
Если нужен быстрый чек: домен, аутентификация, разделение потоков, шаблоны, логирование ошибок доставки. На этом Resend начинает работать как инфраструктура, а не как просто кнопка Send.
This media is not supported in your browser
VIEW IN TELEGRAM
ByteDance анонсировала новую версию SeeDance версии 2.5
ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5
🧠 Ещё больше инсайтов → в канале AFF.top
ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5
🧠 Ещё больше инсайтов → в канале AFF.top