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
Как выбрать non-React стек для проекта, чтобы не пожалеть через полгода
Если React уже не выглядит автоматическим выбором, смотрите не на «моду», а на форму проекта: контентный сайт, кабинет, SPA, маркетинговые страницы или гибрид. Для каждого сценария у альтернатив свой сильный режим.
— Vue 3 хорош, когда нужна предсказуемая архитектура, много компонентов и команда любит понятный порог входа.
— Svelte/SvelteKit удобны там, где важны скорость сборки интерфейса и минимум бойлерплейта.
— SolidJS чаще выбирают за реактивность без лишних перерисовок, но он требует более аккуратного мышления.
— Astro уместен, если основа — контент, SEO и частичная интерактивность, а не тяжёлый SPA.
Проверяйте не только фреймворк, но и экосистему: роутинг, формы, валидация, тесты, SSR, локализация, работа с дизайном и таблицами. Частая ошибка — выбрать стек по демо, а потом собирать половину проекта из несовместимых пакетов.
Ещё один фильтр: кто будет поддерживать код. Если команда меняется или проект живёт долго, берите то, что проще объяснить, ревьюить и нанимать под него людей. Экзотика окупается только там, где есть явная причина, а не желание попробовать новое.
Лучший выбор — не самый быстрый на бенчмарке, а тот, где вы через полгода не будете переписывать базовую архитектуру.
Если React уже не выглядит автоматическим выбором, смотрите не на «моду», а на форму проекта: контентный сайт, кабинет, SPA, маркетинговые страницы или гибрид. Для каждого сценария у альтернатив свой сильный режим.
— Vue 3 хорош, когда нужна предсказуемая архитектура, много компонентов и команда любит понятный порог входа.
— Svelte/SvelteKit удобны там, где важны скорость сборки интерфейса и минимум бойлерплейта.
— SolidJS чаще выбирают за реактивность без лишних перерисовок, но он требует более аккуратного мышления.
— Astro уместен, если основа — контент, SEO и частичная интерактивность, а не тяжёлый SPA.
Проверяйте не только фреймворк, но и экосистему: роутинг, формы, валидация, тесты, SSR, локализация, работа с дизайном и таблицами. Частая ошибка — выбрать стек по демо, а потом собирать половину проекта из несовместимых пакетов.
Ещё один фильтр: кто будет поддерживать код. Если команда меняется или проект живёт долго, берите то, что проще объяснить, ревьюить и нанимать под него людей. Экзотика окупается только там, где есть явная причина, а не желание попробовать новое.
Лучший выбор — не самый быстрый на бенчмарке, а тот, где вы через полгода не будете переписывать базовую архитектуру.
This media is not supported in your browser
VIEW IN TELEGRAM
Codex уничтожит твой SSD за год
Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…
➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god
🧠 Ещё больше инсайтов → в канале AFF.top
Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…
➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god
🧠 Ещё больше инсайтов → в канале AFF.top
Server Components ломают привычный React-контракт: рендер уже не всегда живёт в браузере
Если вы используете Server Components как «просто способ меньше грузить JS», почти всегда упускаете главное: они меняют границу ответственности между сервером и клиентом. На сервере держите то, что зависит от данных, секретов и тяжёлых библиотек; на клиент отдавайте только интерактивность.
Есть рабочая схема проверки:
— этот фрагмент нужен для клика, фокуса, анимации или локального состояния? значит, client.
— это чтение БД, сборка HTML, форматирование, доступ к env или защищённым API? значит, server.
— компонент тянет большой dependency graph без пользы для браузера? выносите выше по дереву на сервер.
Частая ошибка — тащить через границу слишком много props. Тогда Server Components превращаются в сериализацию «всего подряд», и выигрыш по бандлу исчезает. Ещё хуже — прятать бизнес-логику в client-компонентах только потому, что так привычнее: потом вы платите и за JS, и за повторные запросы, и за сложный hydration.
Проверяйте архитектуру вопросом: можно ли этот экран собрать без доступа к window и без лишнего клиентского состояния? Если да, начинайте с server-части, а интерактивность добавляйте точечно.
Если вы используете Server Components как «просто способ меньше грузить JS», почти всегда упускаете главное: они меняют границу ответственности между сервером и клиентом. На сервере держите то, что зависит от данных, секретов и тяжёлых библиотек; на клиент отдавайте только интерактивность.
Есть рабочая схема проверки:
— этот фрагмент нужен для клика, фокуса, анимации или локального состояния? значит, client.
— это чтение БД, сборка HTML, форматирование, доступ к env или защищённым API? значит, server.
— компонент тянет большой dependency graph без пользы для браузера? выносите выше по дереву на сервер.
Частая ошибка — тащить через границу слишком много props. Тогда Server Components превращаются в сериализацию «всего подряд», и выигрыш по бандлу исчезает. Ещё хуже — прятать бизнес-логику в client-компонентах только потому, что так привычнее: потом вы платите и за JS, и за повторные запросы, и за сложный hydration.
Проверяйте архитектуру вопросом: можно ли этот экран собрать без доступа к window и без лишнего клиентского состояния? Если да, начинайте с server-части, а интерактивность добавляйте точечно.
7 ошибок с Sentry, из-за которых алерты есть, а пользы для команды нет
Sentry часто ставят как «черный ящик для ошибок», но без настройки он быстро превращается в шум. Самая частая проблема — ловят всё подряд: дубликаты, тестовые окружения, локальные падения и старые баги, которые уже не чинят. В итоге релевантные инциденты тонут в потоке.
Что стоит проверить в любом проекте:
— фильтрация окружений: dev, staging и local не должны смешиваться с prod;
— ignore rules для известных ошибок, которые не влияют на пользователя;
— релизы и sourcemaps, иначе stack trace остается набором бесполезных строк;
— теги по сервису, версии, клиенту и маршруту, чтобы искать не вручную;
— алерты не по каждому exception, а по росту новых проблем и regression.
Еще одна ошибка — отправлять в Sentry все подряд через catch. Если логировать каждую мелочь, команда перестает реагировать даже на важные падения. Лучше ловить только то, что реально ломает сценарий: checkout, авторизацию, загрузку данных, webhook-потоки.
Итог простой: Sentry полезен только тогда, когда в нем мало мусора и много контекста. Настройте фильтры, sourcemaps и теги один раз — и потом тратите время не на разбор шума, а на исправление причин.
Sentry часто ставят как «черный ящик для ошибок», но без настройки он быстро превращается в шум. Самая частая проблема — ловят всё подряд: дубликаты, тестовые окружения, локальные падения и старые баги, которые уже не чинят. В итоге релевантные инциденты тонут в потоке.
Что стоит проверить в любом проекте:
— фильтрация окружений: dev, staging и local не должны смешиваться с prod;
— ignore rules для известных ошибок, которые не влияют на пользователя;
— релизы и sourcemaps, иначе stack trace остается набором бесполезных строк;
— теги по сервису, версии, клиенту и маршруту, чтобы искать не вручную;
— алерты не по каждому exception, а по росту новых проблем и regression.
Еще одна ошибка — отправлять в Sentry все подряд через catch. Если логировать каждую мелочь, команда перестает реагировать даже на важные падения. Лучше ловить только то, что реально ломает сценарий: checkout, авторизацию, загрузку данных, webhook-потоки.
Итог простой: Sentry полезен только тогда, когда в нем мало мусора и много контекста. Настройте фильтры, sourcemaps и теги один раз — и потом тратите время не на разбор шума, а на исправление причин.
Railway для бэкенда: когда хостинг удобнее VPS, а когда лучше не начинать
Railway часто берут не за «дешево», а за скорость старта: поднимаешь сервис, БД, переменные окружения и деплой из репы почти без ручной возни.
Удобный сценарий:
— пет-проект, MVP, внутренний сервис
— один-два backend-сервиса + база
— команда, где важнее не DevOps, а быстрый релиз
Но есть наблюдение которое стоит проверить: как только у проекта появляется постоянная нагрузка, нестандартная сеть, много фоновых воркеров или строгий контроль расходов, Railway нужно сравнивать уже не с «простым PaaS», а с альтернативой вроде VPS или более специализированного хостинга.
Перед миграцией туда смотрят на три вещи:
— как считается потребление: CPU, RAM, storage, egress
— насколько просто разделить web, worker и cron
— можно ли без боли восстановить окружение руками вне платформы
Если сервис критичный, не привязывайся к удобству CLI и автодеплоя: держи конфиги в репозитории, миграции — отдельно, а БД и секреты — так, чтобы их можно было перенести без магии.
Railway хорош, пока он экономит время сильнее, чем съедает маржу. Если платформа начинает прятать сложность вместо того, чтобы убирать её, это уже повод считать TCO, а не только удобство.
Railway часто берут не за «дешево», а за скорость старта: поднимаешь сервис, БД, переменные окружения и деплой из репы почти без ручной возни.
Удобный сценарий:
— пет-проект, MVP, внутренний сервис
— один-два backend-сервиса + база
— команда, где важнее не DevOps, а быстрый релиз
Но есть наблюдение которое стоит проверить: как только у проекта появляется постоянная нагрузка, нестандартная сеть, много фоновых воркеров или строгий контроль расходов, Railway нужно сравнивать уже не с «простым PaaS», а с альтернативой вроде VPS или более специализированного хостинга.
Перед миграцией туда смотрят на три вещи:
— как считается потребление: CPU, RAM, storage, egress
— насколько просто разделить web, worker и cron
— можно ли без боли восстановить окружение руками вне платформы
Если сервис критичный, не привязывайся к удобству CLI и автодеплоя: держи конфиги в репозитории, миграции — отдельно, а БД и секреты — так, чтобы их можно было перенести без магии.
Railway хорош, пока он экономит время сильнее, чем съедает маржу. Если платформа начинает прятать сложность вместо того, чтобы убирать её, это уже повод считать TCO, а не только удобство.
Resend ломается не на отправке писем, а на настройке домена и вебхуков
Если вы подключаете сервис рассылки в продукт, уязвимое место обычно не API, а инфраструктура вокруг него: SPF, DKIM, DMARC, поддомены для транзакционных писем и обработка bounce/unsubscribe.
Что проверить до первого боевого сценария:
— отдельный поддомен для писем, а не корневой домен;
— DNS-записи без лишних TXT-конфликтов;
— вебхук на delivery/bounce/open с идемпотентной обработкой;
— fallback-логика: если письмо не ушло, задача не должна “зависать”.
Для разработчика Resend удобен тем, что он закрывает отправку быстро и без тяжёлого SMTP-адаптера. Но это не освобождает от дисциплины: одна и та же ошибка в шаблоне, переменной или подписи может молча убить конверсию, а в логах будет выглядеть как “успешно отправлено” ✉️
Ещё один типичный промах — смешивать маркетинговые и продуктовые письма в одном потоке. Разведите их по разным шаблонам, меткам и, по возможности, по доменам. Тогда репутация транзакционных уведомлений не пострадает из-за промо-рассылки.
Если берёте Resend в стек, думайте не про “отправить email”, а про полный маршрут письма: от генерации до подтверждённого delivery.
Если вы подключаете сервис рассылки в продукт, уязвимое место обычно не API, а инфраструктура вокруг него: SPF, DKIM, DMARC, поддомены для транзакционных писем и обработка bounce/unsubscribe.
Что проверить до первого боевого сценария:
— отдельный поддомен для писем, а не корневой домен;
— DNS-записи без лишних TXT-конфликтов;
— вебхук на delivery/bounce/open с идемпотентной обработкой;
— fallback-логика: если письмо не ушло, задача не должна “зависать”.
Для разработчика Resend удобен тем, что он закрывает отправку быстро и без тяжёлого SMTP-адаптера. Но это не освобождает от дисциплины: одна и та же ошибка в шаблоне, переменной или подписи может молча убить конверсию, а в логах будет выглядеть как “успешно отправлено” ✉️
Ещё один типичный промах — смешивать маркетинговые и продуктовые письма в одном потоке. Разведите их по разным шаблонам, меткам и, по возможности, по доменам. Тогда репутация транзакционных уведомлений не пострадает из-за промо-рассылки.
Если берёте Resend в стек, думайте не про “отправить email”, а про полный маршрут письма: от генерации до подтверждённого delivery.
This media is not supported in your browser
VIEW IN TELEGRAM
Google ужесточает модерацию финансовой вертикали
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
Neon: как не ошибиться с Postgres-serverless, если проекту нужен рост без ручного админа
Neon хорош там, где нужен PostgreSQL без постоянного ухода за инстансом: ветки, снапшоты, быстрый старт, отделение compute от storage. Для фриланса, MVP и внутренних сервисов это часто удобнее, чем поднимать классический сервер и следить за его жизнью вручную.
Но у Neon есть ловушка: «serverless» не равно «без ограничений». Сначала проверь сценарий нагрузки. Если у тебя много коротких запросов, всплески трафика и редкие простои — модель подходит. Если же приложение держит постоянные соединения, активно пишет и ожидает предсказуемую задержку, сравни поведение с обычным managed Postgres.
Перед миграцией смотри на 4 вещи:
— пул соединений и совместимость с драйверами;
— размер базы и частоту миграций;
— нужен ли branching для staging/preview;
— как приложение переживёт холодный старт и автопробуждение.
Отдельно проверь бэкапы и откат схемы. Удобство веток не заменяет дисциплину: миграции должны быть обратимыми, а критичные данные — восстанавливаться без ручной магии. Для команд это часто важнее, чем сам факт «облака».
Если проекту нужен Postgres с ветками и без лишней ops-рутины — Neon выглядит разумно. Если нужна стабильная постоянная нагрузка, сначала измерь, а потом переезжай.
Neon хорош там, где нужен PostgreSQL без постоянного ухода за инстансом: ветки, снапшоты, быстрый старт, отделение compute от storage. Для фриланса, MVP и внутренних сервисов это часто удобнее, чем поднимать классический сервер и следить за его жизнью вручную.
Но у Neon есть ловушка: «serverless» не равно «без ограничений». Сначала проверь сценарий нагрузки. Если у тебя много коротких запросов, всплески трафика и редкие простои — модель подходит. Если же приложение держит постоянные соединения, активно пишет и ожидает предсказуемую задержку, сравни поведение с обычным managed Postgres.
Перед миграцией смотри на 4 вещи:
— пул соединений и совместимость с драйверами;
— размер базы и частоту миграций;
— нужен ли branching для staging/preview;
— как приложение переживёт холодный старт и автопробуждение.
Отдельно проверь бэкапы и откат схемы. Удобство веток не заменяет дисциплину: миграции должны быть обратимыми, а критичные данные — восстанавливаться без ручной магии. Для команд это часто важнее, чем сам факт «облака».
Если проекту нужен Postgres с ветками и без лишней ops-рутины — Neon выглядит разумно. Если нужна стабильная постоянная нагрузка, сначала измерь, а потом переезжай.