Starlette ломается не на роутинге, а на мелочах вокруг ASGI
Starlette часто берут как «лёгкий фундамент» для API, но ошибки обычно сидят не в маршрутах, а в обвязке. Если проект начинает тормозить или вести себя странно, смотрят в middleware, работу с ответами и поток запросов, а не в сам endpoint.
Три места, где чаще всего прячется боль:
— тяжёлый middleware на каждом запросе;
— синхронный код внутри async-хендлера;
— чтение тела запроса больше одного раза без буфера.
Ещё одна типовая ловушка — смешивать ответственность. Когда endpoint одновременно валидирует, ходит в БД, форматирует ответ и пишет логи, отладка превращается в квест. В Starlette лучше держать слой маршрутизации тонким: запрос принял, данные передал, ответ вернул.
Полезный тест для любого проекта: если убрать один middleware или вынести один sync-вызов в отдельный threadpool, поведение сразу меняется — узкое место уже найдено. Это почти всегда дешевле, чем переписывать весь стек.
Starlette часто берут как «лёгкий фундамент» для API, но ошибки обычно сидят не в маршрутах, а в обвязке. Если проект начинает тормозить или вести себя странно, смотрят в middleware, работу с ответами и поток запросов, а не в сам endpoint.
Три места, где чаще всего прячется боль:
— тяжёлый middleware на каждом запросе;
— синхронный код внутри async-хендлера;
— чтение тела запроса больше одного раза без буфера.
Ещё одна типовая ловушка — смешивать ответственность. Когда endpoint одновременно валидирует, ходит в БД, форматирует ответ и пишет логи, отладка превращается в квест. В Starlette лучше держать слой маршрутизации тонким: запрос принял, данные передал, ответ вернул.
Полезный тест для любого проекта: если убрать один middleware или вынести один sync-вызов в отдельный threadpool, поведение сразу меняется — узкое место уже найдено. Это почти всегда дешевле, чем переписывать весь стек.
Scrapy ломается не на парсинге, а на мелочах вокруг него
За неделю в репах чаще всего всплывают одни и те же ошибки: crawler быстро «успешно» завершился, а данных меньше ожидаемого; дубли полезли после смены пагинации; proxy и антибот начали резать не запрос, а весь поток. У Scrapy сильный движок, но он не спасает от плохой логики обхода.
Проверь три вещи до запуска:
—
—
—
Ещё одна частая ловушка — смешивать сбор и очистку. Spider должен доставать структуру, а не чинить кривой HTML, считать валюты и решать, куда сохранить результат. Когда в один класс пихают всё подряд, отладка превращается в угадайку.
Если нужен устойчивый краулер, держи правило простым: spider собирает, pipeline валидирует, middleware управляет сетью. Тогда Scrapy остаётся быстрым и предсказуемым, а не «магией, которая иногда работает».
За неделю в репах чаще всего всплывают одни и те же ошибки: crawler быстро «успешно» завершился, а данных меньше ожидаемого; дубли полезли после смены пагинации; proxy и антибот начали резать не запрос, а весь поток. У Scrapy сильный движок, но он не спасает от плохой логики обхода.
Проверь три вещи до запуска:
—
dupefilter: если URL отличаются только параметром, нормализуй их заранее.—
item pipeline: не клади туда тяжёлую бизнес-логику, иначе упадёт throughput.—
retry/timeout: одинаковые настройки для всех доменов редко работают, делай их на уровне spider или downloader middleware.Ещё одна частая ловушка — смешивать сбор и очистку. Spider должен доставать структуру, а не чинить кривой HTML, считать валюты и решать, куда сохранить результат. Когда в один класс пихают всё подряд, отладка превращается в угадайку.
Если нужен устойчивый краулер, держи правило простым: spider собирает, pipeline валидирует, middleware управляет сетью. Тогда Scrapy остаётся быстрым и предсказуемым, а не «магией, которая иногда работает».
Автоматизация ломается не в коде, а в допущениях: 5 мест для проверки
Автоматизация в Python обычно стартует с простого скрипта: забрать данные, преобразовать, отправить дальше. И почти всегда падает не на логике, а на краях: пустой ответ, дубли, таймаут, смена порядка полей.
Проверьте эти точки до запуска в прод:
— входные данные: что делаем с None, пустой строкой, невалидным JSON
— идемпотентность: можно ли повторить запуск без двойной записи
— ретраи: на каких ошибках повторяем, а на каких сразу стоп
— лимиты: есть ли пауза, батчинг, backoff, очереди
— логирование: по логам видно, какой шаг сломался и с какими данными
Для скриптов, которые ходят во внешние API, полезно отделять транспорт от бизнес-логики. Тогда смена клиента, прокси, способа авторизации или формата ответа не размазывает правки по всему проекту. В Django и FastAPI это особенно заметно: один сервисный слой переживает и Celery, и cron, и ручной запуск.
Еще одна типовая ошибка — считать автоматизацию “одноразовой”. Скрипт должен уметь пережить частичный провал: сохранить прогресс, не дублировать записи, продолжить с места остановки. Иначе любой сбой превращается в ручную пересборку пайплайна.
Если скрипт нельзя безопасно запустить дважды и нельзя понять его состояние по логам, это не автоматизация, а хрупкая кнопка.
Автоматизация в Python обычно стартует с простого скрипта: забрать данные, преобразовать, отправить дальше. И почти всегда падает не на логике, а на краях: пустой ответ, дубли, таймаут, смена порядка полей.
Проверьте эти точки до запуска в прод:
— входные данные: что делаем с None, пустой строкой, невалидным JSON
— идемпотентность: можно ли повторить запуск без двойной записи
— ретраи: на каких ошибках повторяем, а на каких сразу стоп
— лимиты: есть ли пауза, батчинг, backoff, очереди
— логирование: по логам видно, какой шаг сломался и с какими данными
Для скриптов, которые ходят во внешние API, полезно отделять транспорт от бизнес-логики. Тогда смена клиента, прокси, способа авторизации или формата ответа не размазывает правки по всему проекту. В Django и FastAPI это особенно заметно: один сервисный слой переживает и Celery, и cron, и ручной запуск.
Еще одна типовая ошибка — считать автоматизацию “одноразовой”. Скрипт должен уметь пережить частичный провал: сохранить прогресс, не дублировать записи, продолжить с места остановки. Иначе любой сбой превращается в ручную пересборку пайплайна.
Если скрипт нельзя безопасно запустить дважды и нельзя понять его состояние по логам, это не автоматизация, а хрупкая кнопка.
This media is not supported in your browser
VIEW IN TELEGRAM
Claude скоро станет по паспорту
С 8 июля 2026 года все модели Claude потребуют верификации личности через паспорт и селфи. Это произошло после закрытия доступа к Fable 5, выпущенной в открытый доступ буквально на неделю. Ограничение касается веб-версии на сайте Anthropic, но остаётся неясным, будут ли верификацию требовать API и AI-агенты вроде Codex. Решение выглядит излишне строгим в свете качества моделей, однако компания явно ужесточает контроль над доступом к своим продук…
➡️ Читайте на сайте: https://aff.top/blog/claude-skoro-stanet-po-pasportu
🧠 Ещё больше инсайтов → в канале AFF.top
С 8 июля 2026 года все модели Claude потребуют верификации личности через паспорт и селфи. Это произошло после закрытия доступа к Fable 5, выпущенной в открытый доступ буквально на неделю. Ограничение касается веб-версии на сайте Anthropic, но остаётся неясным, будут ли верификацию требовать API и AI-агенты вроде Codex. Решение выглядит излишне строгим в свете качества моделей, однако компания явно ужесточает контроль над доступом к своим продук…
➡️ Читайте на сайте: https://aff.top/blog/claude-skoro-stanet-po-pasportu
🧠 Ещё больше инсайтов → в канале AFF.top
7 ошибок на русской CMS, из-за которых сайт «тормозит» даже на хорошем хостинге
На Bitrix и MODX чаще всего упираются не в сервер, а в сборку проекта. Если сайт медленный, сначала смотрят не на тариф, а на типовые косяки в коде и шаблонах.
— Условная логика в каждом запросе. Когда в шаблоне на каждый рендер идут проверки прав, выборки и вычисления, страдает весь фронт.
— Лишние запросы к БД. Классика: циклы с N+1, повторные выборки одних и тех же данных, отсутствие кеширования там, где оно очевидно.
— Тяжёлые компоненты на главной. Часто туда тащат всё подряд: новости, каталоги, формы, баннеры, рекомендации. В итоге одна страница собирает полсайта.
— Картинки без подготовки. Огромные исходники, отсутствие адаптивных размеров и lazy load убивают скорость сильнее, чем кажется.
— Скрипты и стили без дисциплины. Когда подключено всё сразу, даже простой интерфейс начинает грузиться как портал.
Отдельно проверяйте, не ломает ли кастомизация встроенный кеш CMS. Если кеш есть, но постоянно сбрасывается, пользы от него почти нет.
Самый рабочий порядок такой: сначала убрать лишние запросы и тяжёлые блоки, потом оптимизировать медиа, и только после этого трогать сервер.
На Bitrix и MODX чаще всего упираются не в сервер, а в сборку проекта. Если сайт медленный, сначала смотрят не на тариф, а на типовые косяки в коде и шаблонах.
— Условная логика в каждом запросе. Когда в шаблоне на каждый рендер идут проверки прав, выборки и вычисления, страдает весь фронт.
— Лишние запросы к БД. Классика: циклы с N+1, повторные выборки одних и тех же данных, отсутствие кеширования там, где оно очевидно.
— Тяжёлые компоненты на главной. Часто туда тащат всё подряд: новости, каталоги, формы, баннеры, рекомендации. В итоге одна страница собирает полсайта.
— Картинки без подготовки. Огромные исходники, отсутствие адаптивных размеров и lazy load убивают скорость сильнее, чем кажется.
— Скрипты и стили без дисциплины. Когда подключено всё сразу, даже простой интерфейс начинает грузиться как портал.
Отдельно проверяйте, не ломает ли кастомизация встроенный кеш CMS. Если кеш есть, но постоянно сбрасывается, пользы от него почти нет.
Самый рабочий порядок такой: сначала убрать лишние запросы и тяжёлые блоки, потом оптимизировать медиа, и только после этого трогать сервер.
Elementor тормозит не из-за плагина, а из-за того, как его собирают
У Elementor есть типовая ловушка: сначала делают страницу «на всём подряд», потом ищут виноватый кэш. На арбитражных лендингах это бьёт особенно быстро: лишние секции, вложенные контейнеры, анимации, иконки, виджеты ради одного абзаца.
Перед запуском проверьте три вещи:
— не больше одного визуального конструктора на странице;
— меньше вложенности в шаблоне, особенно в хедере и футере;
— не тащить виджеты, которые не влияют на конверсию.
Есть наблюдение которое стоит проверить: тяжёлый Elementor-проект чаще всего выигрывает не от «ускорителей», а от вычищенной структуры. Когда убирают дублирующие блоки, сокращают CSS/JS от лишних модулей и переводят повторяющиеся элементы в шаблоны, у страницы резко падает шум.
Ещё один простой тест: откройте страницу без анимаций, с минимальным набором виджетов и сравните поведение формы, кнопок и первого экрана. Если логика не ломается, значит половина «красоты» была лишней. Для WP-сетки это почти всегда лучший путь.
Сначала собирайте лендинг как рабочий интерфейс, потом как витрину. На Elementor это экономит и скорость, и нервы, и место для реальной конверсии.
У Elementor есть типовая ловушка: сначала делают страницу «на всём подряд», потом ищут виноватый кэш. На арбитражных лендингах это бьёт особенно быстро: лишние секции, вложенные контейнеры, анимации, иконки, виджеты ради одного абзаца.
Перед запуском проверьте три вещи:
— не больше одного визуального конструктора на странице;
— меньше вложенности в шаблоне, особенно в хедере и футере;
— не тащить виджеты, которые не влияют на конверсию.
Есть наблюдение которое стоит проверить: тяжёлый Elementor-проект чаще всего выигрывает не от «ускорителей», а от вычищенной структуры. Когда убирают дублирующие блоки, сокращают CSS/JS от лишних модулей и переводят повторяющиеся элементы в шаблоны, у страницы резко падает шум.
Ещё один простой тест: откройте страницу без анимаций, с минимальным набором виджетов и сравните поведение формы, кнопок и первого экрана. Если логика не ломается, значит половина «красоты» была лишней. Для WP-сетки это почти всегда лучший путь.
Сначала собирайте лендинг как рабочий интерфейс, потом как витрину. На Elementor это экономит и скорость, и нервы, и место для реальной конверсии.
ESM ломает не код, а допущения: проверь их до первого импорта
В CommonJS многие ошибки прячутся за require и module.exports. В ESM они выходят наружу сразу: строгие пути, явные расширения, отдельные правила для default и named export.
Три места, где чаще всего спотыкаются:
— импорт без расширения в Node-окружении;
— смешивание default export и named export «на глаз»;
— циклические зависимости, которые в ESM проявляются жёстче, чем в CJS.
Если проект уже живёт на TypeScript, проверь связку tsconfig и рантайма. Для сборки важно, чтобы moduleResolution, target и формат выхода не спорили между собой. Иначе код проходит typecheck, но падает при запуске или в тестах.
Отдельно смотри на библиотеки и утилиты: не всё, что красиво импортируется в Vite, так же работает в Node, Bun или при прямом запуске через tsx. ESM любит явность. Чем меньше магии в путях и экспортах, тем меньше сюрпризов в деплое.
Если мигрируешь репу на ESM, начни с одного правила: сначала стабилизируй импорты, потом меняй формат модулей. Это почти всегда дешевле, чем чинить уже собранный стек.
В CommonJS многие ошибки прячутся за require и module.exports. В ESM они выходят наружу сразу: строгие пути, явные расширения, отдельные правила для default и named export.
Три места, где чаще всего спотыкаются:
— импорт без расширения в Node-окружении;
— смешивание default export и named export «на глаз»;
— циклические зависимости, которые в ESM проявляются жёстче, чем в CJS.
Если проект уже живёт на TypeScript, проверь связку tsconfig и рантайма. Для сборки важно, чтобы moduleResolution, target и формат выхода не спорили между собой. Иначе код проходит typecheck, но падает при запуске или в тестах.
Отдельно смотри на библиотеки и утилиты: не всё, что красиво импортируется в Vite, так же работает в Node, Bun или при прямом запуске через tsx. ESM любит явность. Чем меньше магии в путях и экспортах, тем меньше сюрпризов в деплое.
Если мигрируешь репу на ESM, начни с одного правила: сначала стабилизируй импорты, потом меняй формат модулей. Это почти всегда дешевле, чем чинить уже собранный стек.
5 ошибок во Vue-проекте, которые потом превращаются в долгий техдолг
Vue обычно про скорость разработки, но типовые промахи потом бьют по поддержке. Первый — хранить слишком много состояния в компоненте, когда часть логики уже просится в composable или store. Второй — смешивать UI, запросы и форматирование в одном файле: компонент растёт, а тестировать его всё больнее.
Ещё две частые проблемы:
— неглубокая структура компонентов, где всё лежит в одном месте и любая правка задевает соседей;
— реактивность “на удачу”, когда computed и watch используют вместо понятной модели данных, а потом ловят лишние перерендеры и скрытые циклы.
Отдельно стоит смотреть на шаблоны: если там много условий, инлайн-функций и тяжёлых вычислений, это почти всегда сигнал вынести логику выше. Иначе код выглядит простым только до первого рефакторинга.
Хорошая проверка для любого Vue-модуля: если компонент нельзя объяснить за 30 секунд, значит он уже делает лишнее. Разрежьте его на визуальный слой, состояние и побочные эффекты — и сопровождать проект станет заметно легче.
Vue обычно про скорость разработки, но типовые промахи потом бьют по поддержке. Первый — хранить слишком много состояния в компоненте, когда часть логики уже просится в composable или store. Второй — смешивать UI, запросы и форматирование в одном файле: компонент растёт, а тестировать его всё больнее.
Ещё две частые проблемы:
— неглубокая структура компонентов, где всё лежит в одном месте и любая правка задевает соседей;
— реактивность “на удачу”, когда computed и watch используют вместо понятной модели данных, а потом ловят лишние перерендеры и скрытые циклы.
Отдельно стоит смотреть на шаблоны: если там много условий, инлайн-функций и тяжёлых вычислений, это почти всегда сигнал вынести логику выше. Иначе код выглядит простым только до первого рефакторинга.
Хорошая проверка для любого Vue-модуля: если компонент нельзя объяснить за 30 секунд, значит он уже делает лишнее. Разрежьте его на визуальный слой, состояние и побочные эффекты — и сопровождать проект станет заметно легче.
FastAPI ломают не роуты, а неправильные зависимости и валидация
За неделю в репах чаще всего всплывает одна и та же проблема: проект стартует быстро, а потом начинает тормозить на интеграциях. Причина обычно не в самом FastAPI, а в том, как собраны зависимости, схемы и фоновые задачи.
• Не тащите тяжёлую работу в endpoint. Всё, что ходит во внешние API, пишет файлы или собирает отчёты, уносите в очередь или background task.
• Не делайте pydantic-модели «на всё». Отдельно держите request, response и internal schema — иначе валидация превращается в кашу.
• Не смешивайте бизнес-логику с роутом. Endpoint должен принять данные, вызвать сервис и вернуть ответ, а не решать половину доменной задачи.
Есть наблюдение которое стоит проверить: большинство багов в FastAPI появляется не на async, а на границе слоёв. Там, где один и тот же объект живёт в SQLAlchemy, в ответе API и в тестах, начинаются сюрпризы с мутацией, сериализацией и лишними запросами.
Ещё один частый провал — зависимость через глобальные синглтоны. Для подключения к БД, клиентам и конфигу лучше использовать явную dependency injection: так тесты проще, а код не привязан к магии импорта.
Если FastAPI кажется «простым», это обычно до первого роста проекта. Держите роуты тонкими, схемы раздельными, а IO — вне синхронного пути, и приложение останется читаемым без героизма.
За неделю в репах чаще всего всплывает одна и та же проблема: проект стартует быстро, а потом начинает тормозить на интеграциях. Причина обычно не в самом FastAPI, а в том, как собраны зависимости, схемы и фоновые задачи.
• Не тащите тяжёлую работу в endpoint. Всё, что ходит во внешние API, пишет файлы или собирает отчёты, уносите в очередь или background task.
• Не делайте pydantic-модели «на всё». Отдельно держите request, response и internal schema — иначе валидация превращается в кашу.
• Не смешивайте бизнес-логику с роутом. Endpoint должен принять данные, вызвать сервис и вернуть ответ, а не решать половину доменной задачи.
Есть наблюдение которое стоит проверить: большинство багов в FastAPI появляется не на async, а на границе слоёв. Там, где один и тот же объект живёт в SQLAlchemy, в ответе API и в тестах, начинаются сюрпризы с мутацией, сериализацией и лишними запросами.
Ещё один частый провал — зависимость через глобальные синглтоны. Для подключения к БД, клиентам и конфигу лучше использовать явную dependency injection: так тесты проще, а код не привязан к магии импорта.
Если FastAPI кажется «простым», это обычно до первого роста проекта. Держите роуты тонкими, схемы раздельными, а IO — вне синхронного пути, и приложение останется читаемым без героизма.
7 ошибок в Python-скриптах, из-за которых автоматизация ломается на ровном месте
В Python чаще всего падает не «логика», а обвязка: ввод, сеть, файлы, окружение. Если скрипт живёт дольше одного запуска, проверь базу:
— не ловишь ли ты исключения через голый except;
— не смешиваешь ли print и нормальный logging;
— не рассчитываешь ли на порядок в dict там, где нужен явный сорт;
— не читаешь ли файл целиком, когда хватит итерации по строкам.
Ещё одна типовая проблема — скрытые зависимости. Скрипт работает у тебя, но ломается на сервере, потому что путь относительный, переменные окружения не заданы, а формат входных данных чуть отличается. Сюда же относятся:
— жёстко прошитые URL, токены и пути;
— отсутствие проверок на пустой ответ;
— работа без таймаутов для запросов;
— ожидание, что внешний сервис всегда вернёт JSON.
Если есть асинхронщина, отдельно смотри на блокировки: один случайный requests, тяжёлый парсинг или синхронный драйвер внутри event loop убивают смысл asyncio. Для фоновых задач полезно сразу разделять: I/O отдельно, CPU отдельно, ошибки отдельно.
Хороший скрипт — это не тот, который «один раз отработал», а тот, который переживает пустые данные, сетевые сбои и чужую среду. Перед запуском в проде прогоняй чек: вход, таймауты, логи, конфиг, исключения, и только потом логику.
В Python чаще всего падает не «логика», а обвязка: ввод, сеть, файлы, окружение. Если скрипт живёт дольше одного запуска, проверь базу:
— не ловишь ли ты исключения через голый except;
— не смешиваешь ли print и нормальный logging;
— не рассчитываешь ли на порядок в dict там, где нужен явный сорт;
— не читаешь ли файл целиком, когда хватит итерации по строкам.
Ещё одна типовая проблема — скрытые зависимости. Скрипт работает у тебя, но ломается на сервере, потому что путь относительный, переменные окружения не заданы, а формат входных данных чуть отличается. Сюда же относятся:
— жёстко прошитые URL, токены и пути;
— отсутствие проверок на пустой ответ;
— работа без таймаутов для запросов;
— ожидание, что внешний сервис всегда вернёт JSON.
Если есть асинхронщина, отдельно смотри на блокировки: один случайный requests, тяжёлый парсинг или синхронный драйвер внутри event loop убивают смысл asyncio. Для фоновых задач полезно сразу разделять: I/O отдельно, CPU отдельно, ошибки отдельно.
Хороший скрипт — это не тот, который «один раз отработал», а тот, который переживает пустые данные, сетевые сбои и чужую среду. Перед запуском в проде прогоняй чек: вход, таймауты, логи, конфиг, исключения, и только потом логику.
Скрипт должен падать предсказуемо: 6 проверок до запуска в прод
Если python-скрипт живёт дольше одного запуска, его надо проверять не “на глаз”, а по схеме. Иначе он ломается там, где не ждёшь: на пустом файле, на кривой кодировке, на повторной записи, на таймауте API.
— Сначала проверяй вход: файл существует, формат тот, кодировка читается, обязательные поля не пустые.
— Потом ограничивай объём: лимит на размер файла, число строк, глубину рекурсии, размер ответа от внешнего сервиса.
— Любой внешний вызов оборачивай в retry + timeout, но retry делай только для идемпотентных операций.
— Логи пиши так, чтобы по одному сообщению было ясно: что обрабатывали, на каком шаге упали, какой был payload.
— Ошибки дели на ожидаемые и аварийные: первые обрабатывай, вторые пусть валят задачу с понятным trace.
Отдельная ловушка — временные файлы и частичные записи. Сначала пишешь в tmp, потом атомарно переименовываешь; иначе после падения у тебя остаётся “почти готовый” результат, который кто-то примет за валидный.
И ещё: любой скрипт без теста на один плохой кейс — это не автоматизация, а надежда. Лучше один раз зашить проверки, чем потом вручную искать, где именно всё съехало.
Если python-скрипт живёт дольше одного запуска, его надо проверять не “на глаз”, а по схеме. Иначе он ломается там, где не ждёшь: на пустом файле, на кривой кодировке, на повторной записи, на таймауте API.
— Сначала проверяй вход: файл существует, формат тот, кодировка читается, обязательные поля не пустые.
— Потом ограничивай объём: лимит на размер файла, число строк, глубину рекурсии, размер ответа от внешнего сервиса.
— Любой внешний вызов оборачивай в retry + timeout, но retry делай только для идемпотентных операций.
— Логи пиши так, чтобы по одному сообщению было ясно: что обрабатывали, на каком шаге упали, какой был payload.
— Ошибки дели на ожидаемые и аварийные: первые обрабатывай, вторые пусть валят задачу с понятным trace.
Отдельная ловушка — временные файлы и частичные записи. Сначала пишешь в tmp, потом атомарно переименовываешь; иначе после падения у тебя остаётся “почти готовый” результат, который кто-то примет за валидный.
И ещё: любой скрипт без теста на один плохой кейс — это не автоматизация, а надежда. Лучше один раз зашить проверки, чем потом вручную искать, где именно всё съехало.
React Server Actions ломают границы между UI и мутирующей логикой — и это надо проектировать заранее
Server Actions удобно вешать на форму и забывать про отдельный API-слой. Но если рядом уже живут TanStack Query, optimistic UI и сложная авторизация, начинаются дубли: одно и то же действие вызывают из формы, модалки и фонового процесса.
Перед внедрением проверьте три вещи:
— где проходит граница между чтением и записью;
— кто владеет инвалидцией кеша;
— можно ли вызвать действие не из браузерной формы, а из обработчика, теста или cron-джобы.
Главная ошибка — тащить в Action всю бизнес-логику. Тогда её сложно переиспользовать, мокать и переносить между Next.js, Remix и обычным backend-for-frontend. Лучше держать Action тонким адаптером: валидация, вызов доменного сервиса, возврат результата.
И ещё одно: Action не отменяет необходимость явных контрактов. Если на выходе у вас меняются поля, сообщения об ошибке и побочные эффекты, фронт быстро превращается в набор хрупких допущений. Разделяйте: Action для транспорта, сервис для правил, схема для данных.
Server Actions удобно вешать на форму и забывать про отдельный API-слой. Но если рядом уже живут TanStack Query, optimistic UI и сложная авторизация, начинаются дубли: одно и то же действие вызывают из формы, модалки и фонового процесса.
Перед внедрением проверьте три вещи:
— где проходит граница между чтением и записью;
— кто владеет инвалидцией кеша;
— можно ли вызвать действие не из браузерной формы, а из обработчика, теста или cron-джобы.
Главная ошибка — тащить в Action всю бизнес-логику. Тогда её сложно переиспользовать, мокать и переносить между Next.js, Remix и обычным backend-for-frontend. Лучше держать Action тонким адаптером: валидация, вызов доменного сервиса, возврат результата.
И ещё одно: Action не отменяет необходимость явных контрактов. Если на выходе у вас меняются поля, сообщения об ошибке и побочные эффекты, фронт быстро превращается в набор хрупких допущений. Разделяйте: Action для транспорта, сервис для правил, схема для данных.
This media is not supported in your browser
VIEW IN TELEGRAM
Google выпустил Android 17
Android получил встроенную Gemini с функциями автоматизации задач, конспектирования браузера и редактирования медиа. Обновление принесло новый интерфейс Bubble, двухкамерную запись и игровой режим для складных телефонов. Критический момент: Gemini Intelligence требует Gemini Nano v3 и минимум 12 ГБ RAM, что ограничивает аудиторию премиум-девайсов. Это создаёт потенциал для таргетинга криптооффера на узкий сегмент владельцев флагманов, готовых пл…
➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-android-17
🧠 Ещё больше инсайтов → в канале AFF.top
Android получил встроенную Gemini с функциями автоматизации задач, конспектирования браузера и редактирования медиа. Обновление принесло новый интерфейс Bubble, двухкамерную запись и игровой режим для складных телефонов. Критический момент: Gemini Intelligence требует Gemini Nano v3 и минимум 12 ГБ RAM, что ограничивает аудиторию премиум-девайсов. Это создаёт потенциал для таргетинга криптооффера на узкий сегмент владельцев флагманов, готовых пл…
➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-android-17
🧠 Ещё больше инсайтов → в канале AFF.top
Firebase в WebView: какие события собирать, чтобы не сломать арбитражную аналитику
В WebView аналитика ломается не из-за Firebase, а из-за хаотичной схемы событий. Если сразу не развести web-сигналы и app-сигналы, вы увидите красивый, но бесполезный график: установка есть, а где отвалился трафик — неясно.
Что важно: собирайте только те точки, которые помогают управлять воронкой. Минимум: first_open, view_item, lead_start, lead_submit, purchase/dep, plus кастомные шаги для формы, оплаты и ошибок. Для арбитража полезнее не “все клики подряд”, а 2–3 ключевых этапа в каждом экране.
На практике: передавайте в event_params source, campaign, adset, creative и placement, но не тащите в аналитику мусорный кликстрим. Иначе в отчетах будет много строк, а решений — мало. Для WebView отдельно помечайте переходы между страницей, формой и внешним SDK-экраном, чтобы видеть, где именно падает конверсия.
Еще один момент — дедупликация. Если WebView перезагружается или пользователь возвращается назад, одно и то же событие может улететь повторно. Ставьте session_id, stable user_id и защиту от дублей на стороне приложения или бэка. Это спасает от ложного роста CR и неправильных выводов по крео.
Соберите сначала каркас событий, потом уже расширяйте его под конкретный оффер. В арбитраже аналитика ценна не количеством метрик, а тем, насколько быстро она отвечает на вопрос: где теряется деньги.
В WebView аналитика ломается не из-за Firebase, а из-за хаотичной схемы событий. Если сразу не развести web-сигналы и app-сигналы, вы увидите красивый, но бесполезный график: установка есть, а где отвалился трафик — неясно.
Что важно: собирайте только те точки, которые помогают управлять воронкой. Минимум: first_open, view_item, lead_start, lead_submit, purchase/dep, plus кастомные шаги для формы, оплаты и ошибок. Для арбитража полезнее не “все клики подряд”, а 2–3 ключевых этапа в каждом экране.
На практике: передавайте в event_params source, campaign, adset, creative и placement, но не тащите в аналитику мусорный кликстрим. Иначе в отчетах будет много строк, а решений — мало. Для WebView отдельно помечайте переходы между страницей, формой и внешним SDK-экраном, чтобы видеть, где именно падает конверсия.
Еще один момент — дедупликация. Если WebView перезагружается или пользователь возвращается назад, одно и то же событие может улететь повторно. Ставьте session_id, stable user_id и защиту от дублей на стороне приложения или бэка. Это спасает от ложного роста CR и неправильных выводов по крео.
Соберите сначала каркас событий, потом уже расширяйте его под конкретный оффер. В арбитраже аналитика ценна не количеством метрик, а тем, насколько быстро она отвечает на вопрос: где теряется деньги.
Три audited no-log VPN: кто не требует email и не ведёт аффилиатов
Mullvad выдаёт номер аккаунта без привязки к почте. Принимают наличные и Monero, серверы работают в RAM, регулярно проходят аудиты. Минус — нет рефералок и маркетинговых плюшек, что для инфраструктуры плюс.
ProtonVPN даёт швейцарскую юрисдикцию и Secure Core с двойным хопом. Требует email при регистрации, хотя и поддерживает крипту. Инфраструктура проверена аудиторами, но freemium-модель создаёт поверхность для атаки через бесплатные узлы.
IVPN регистрирует без email, принимает наличные, не платит аффилиатам и не покупает рекламу. Gibraltar — не Five Eyes, но и не Швейцария. Сеть меньше, зато политика приватности прозрачнее некуда.
На практике: если нужен максимально анонимный аккаунт — Mullvad или IVPN. Если важна юрисдикция и мульти-хоп — ProtonVPN. Для арбитражных задач все три заменят IP, но для личной приватности выбирайте по принципу «чем меньше данных оставили при регистрации — тем лучше».
Проверка длины без HTML:
Mullvad выдаёт номер аккаунта без привязки к почте. Принимают наличные и Monero, серверы работают в RAM, регулярно проходят аудиты. Минус — нет рефералок и маркетинговых плюшек, что для инфраструктуры плюс.
ProtonVPN даёт швейцарскую юрисдикцию и Secure Core с двойным хопом. Требует email при регистрации, хотя и поддерживает крипту. Инфраструктура проверена аудиторами, но freemium-модель создаёт поверхность для атаки через бесплатные узлы.
IVPN регистрирует без email, принимает наличные, не платит аффилиатам и не покупает рекламу. Gibraltar — не Five Eyes, но и не Швейцария. Сеть меньше, зато политика приватности прозрачнее некуда.
На практике: если нужен максимально анонимный аккаунт — Mullvad или IVPN. Если важна юрисдикция и мульти-хоп — ProtonVPN. Для арбитражных задач все три заменят IP, но для личной приватности выбирайте по принципу «чем меньше данных оставили при регистрации — тем лучше».
Посчитаем символы:
Аб
Mullvad выдаёт номер аккаунта без привязки к почте. Принимают наличные и Monero, серверы работают в RAM, регулярно проходят аудиты. Минус — нет рефералок и маркетинговых плюшек, что для инфраструктуры плюс.
ProtonVPN даёт швейцарскую юрисдикцию и Secure Core с двойным хопом. Требует email при регистрации, хотя и поддерживает крипту. Инфраструктура проверена аудиторами, но freemium-модель создаёт поверхность для атаки через бесплатные узлы.
IVPN регистрирует без email, принимает наличные, не платит аффилиатам и не покупает рекламу. Gibraltar — не Five Eyes, но и не Швейцария. Сеть меньше, зато политика приватности прозрачнее некуда.
На практике: если нужен максимально анонимный аккаунт — Mullvad или IVPN. Если важна юрисдикция и мульти-хоп — ProtonVPN. Для арбитражных задач все три заменят IP, но для личной приватности выбирайте по принципу «чем меньше данных оставили при регистрации — тем лучше».
Проверка длины без HTML:
Mullvad выдаёт номер аккаунта без привязки к почте. Принимают наличные и Monero, серверы работают в RAM, регулярно проходят аудиты. Минус — нет рефералок и маркетинговых плюшек, что для инфраструктуры плюс.
ProtonVPN даёт швейцарскую юрисдикцию и Secure Core с двойным хопом. Требует email при регистрации, хотя и поддерживает крипту. Инфраструктура проверена аудиторами, но freemium-модель создаёт поверхность для атаки через бесплатные узлы.
IVPN регистрирует без email, принимает наличные, не платит аффилиатам и не покупает рекламу. Gibraltar — не Five Eyes, но и не Швейцария. Сеть меньше, зато политика приватности прозрачнее некуда.
На практике: если нужен максимально анонимный аккаунт — Mullvad или IVPN. Если важна юрисдикция и мульти-хоп — ProtonVPN. Для арбитражных задач все три заменят IP, но для личной приватности выбирайте по принципу «чем меньше данных оставили при регистрации — тем лучше».
Посчитаем символы:
Аб
Flask ломают не роуты, а отсутствие границ между кодом и инфраструктурой
В Flask слишком легко начать с «одного файла» и незаметно притащить в него всё: конфиг, бизнес-логику, SQL, шаблоны, интеграции. Через месяц такой app.py уже не поддерживается, а любой новый эндпоинт требует раскопок по всему проекту.
Рабочая схема простая:
— app factory вместо глобального app;
— blueprints для разрезания домена по модулям;
— отдельные слои для сервисов, репозиториев и адаптеров;
— конфиг через окружение, а не через хардкод;
— расширения и middleware подключать в одном месте, а не по всему коду.
Ещё одна типовая ошибка — тащить в view всё подряд. View должен принимать запрос, валидировать вход, вызвать сервис и вернуть ответ. Если в нём есть SQL-запросы, HTTP-клиенты и ветвления на 80 строк, проект уже не Flask-лайт, а монолит без структуры.
Для фоновых задач и внешних интеграций лучше сразу отделять их от request-response цикла: очереди, отдельные воркеры, явные таймауты и ретраи. Иначе любой медленный API начнёт тормозить весь веб-поток.
Если Flask нужен в проде, держите его как тонкий HTTP-слой, а не как место, где живёт вся логика. Тогда приложение остаётся маленьким по коду, но большим по масштабу.
В Flask слишком легко начать с «одного файла» и незаметно притащить в него всё: конфиг, бизнес-логику, SQL, шаблоны, интеграции. Через месяц такой app.py уже не поддерживается, а любой новый эндпоинт требует раскопок по всему проекту.
Рабочая схема простая:
— app factory вместо глобального app;
— blueprints для разрезания домена по модулям;
— отдельные слои для сервисов, репозиториев и адаптеров;
— конфиг через окружение, а не через хардкод;
— расширения и middleware подключать в одном месте, а не по всему коду.
Ещё одна типовая ошибка — тащить в view всё подряд. View должен принимать запрос, валидировать вход, вызвать сервис и вернуть ответ. Если в нём есть SQL-запросы, HTTP-клиенты и ветвления на 80 строк, проект уже не Flask-лайт, а монолит без структуры.
Для фоновых задач и внешних интеграций лучше сразу отделять их от request-response цикла: очереди, отдельные воркеры, явные таймауты и ретраи. Иначе любой медленный API начнёт тормозить весь веб-поток.
Если Flask нужен в проде, держите его как тонкий HTTP-слой, а не как место, где живёт вся логика. Тогда приложение остаётся маленьким по коду, но большим по масштабу.
Scrapy ломается не на парсинге, а на грязном каркасе проекта
За неделю в репах: у рабочих краулеров чаще всего текут не селекторы, а архитектура. Если Spider знает про БД, ретраи и формат выгрузки, его почти невозможно переиспользовать без боли.
Держите три слоя отдельно:
— Spider: только запросы и извлечение полей
— Pipeline: валидация, нормализация, запись
— Item: единая схема данных, а не «dict как получится»
Самые частые ошибки в Scrapy:
— дубли из-за слабого
— падения на пустых полях, когда нет
— тяжёлые
Если проект растёт, сразу добавляйте:
— явные таймауты и лимиты на глубину
— отдельный слой для экспорта в CSV/JSON/БД
— логирование причин пропуска, а не только ошибок
Scrapy хорош там, где поток данных должен быть предсказуемым. Чем раньше вы отделите сбор от обработки, тем меньше времени уйдёт на «починку парсера» вместо работы с данными.
За неделю в репах: у рабочих краулеров чаще всего текут не селекторы, а архитектура. Если Spider знает про БД, ретраи и формат выгрузки, его почти невозможно переиспользовать без боли.
Держите три слоя отдельно:
— Spider: только запросы и извлечение полей
— Pipeline: валидация, нормализация, запись
— Item: единая схема данных, а не «dict как получится»
Самые частые ошибки в Scrapy:
— дубли из-за слабого
dupefilter и кривых start_urls— падения на пустых полях, когда нет
default и проверки типов— тяжёлые
parse-методы, где внутри и логика, и сеть, и форматированиеЕсли проект растёт, сразу добавляйте:
— явные таймауты и лимиты на глубину
— отдельный слой для экспорта в CSV/JSON/БД
— логирование причин пропуска, а не только ошибок
Scrapy хорош там, где поток данных должен быть предсказуемым. Чем раньше вы отделите сбор от обработки, тем меньше времени уйдёт на «починку парсера» вместо работы с данными.
Starlette ломают не роуты, а мелкие ошибки в ASGI-границах
Starlette часто берут как «лёгкий каркас», а потом удивляются странным багам под нагрузкой. За неделю в репах обычно всплывают одни и те же места: request body читают дважды, фоновые задачи начинают жить своей жизнью, middleware меняет поведение ответа уже после отправки.
Проверьте базовый набор:
— не читайте stream/body в разных слоях без явного кеша;
— не держите тяжёлую логику в middleware, если она может быть зависимостью или endpoint-ом;
— не смешивайте sync-код с async без понятного границами вызова;
— для долгих операций выносите работу в очередь, а не в response cycle.
Ещё одна частая проблема — обработка исключений. Если вы ловите всё подряд и возвращаете «красивый» 200, отладка превращается в археологию. Лучше явно разделять: валидация, ожидаемые доменные ошибки, и настоящий 500 с логом и trace-id.
Если Starlette кажется капризным, обычно каприз не в нём, а в том, что в приложении не определены границы ответственности. Держите transport, бизнес-логику и фоновые задачи раздельно — и каркас перестаёт удивлять.
Starlette часто берут как «лёгкий каркас», а потом удивляются странным багам под нагрузкой. За неделю в репах обычно всплывают одни и те же места: request body читают дважды, фоновые задачи начинают жить своей жизнью, middleware меняет поведение ответа уже после отправки.
Проверьте базовый набор:
— не читайте stream/body в разных слоях без явного кеша;
— не держите тяжёлую логику в middleware, если она может быть зависимостью или endpoint-ом;
— не смешивайте sync-код с async без понятного границами вызова;
— для долгих операций выносите работу в очередь, а не в response cycle.
Ещё одна частая проблема — обработка исключений. Если вы ловите всё подряд и возвращаете «красивый» 200, отладка превращается в археологию. Лучше явно разделять: валидация, ожидаемые доменные ошибки, и настоящий 500 с логом и trace-id.
Если Starlette кажется капризным, обычно каприз не в нём, а в том, что в приложении не определены границы ответственности. Держите transport, бизнес-логику и фоновые задачи раздельно — и каркас перестаёт удивлять.
This media is not supported in your browser
VIEW IN TELEGRAM
Армения заблокирует онлайн-казино для получающих пособия
Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 20% дохода, обязала казино добавить кнопку самозапрета. Сайты, не подчинившиеся требованиям, будут заблокированы — технология реализации неясна. Проблемы с платёжками неизбежны. Криптоказино, вероятно, останутся без контроля, что открывает новый канал для залива трафика.
➡️ Читайте на сайте: https://aff.top/blog/armeniia-zablokiruet-onlain-kazino-dlia-poluchaiuschikh-posobiia
🧠 Ещё больше инсайтов → в канале AFF.top
Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 20% дохода, обязала казино добавить кнопку самозапрета. Сайты, не подчинившиеся требованиям, будут заблокированы — технология реализации неясна. Проблемы с платёжками неизбежны. Криптоказино, вероятно, останутся без контроля, что открывает новый канал для залива трафика.
➡️ Читайте на сайте: https://aff.top/blog/armeniia-zablokiruet-onlain-kazino-dlia-poluchaiuschikh-posobiia
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В DeepSeek добавили распознавание изображений
DeepSeek запустил бета-версию распознавания изображений — функция доступна бесплатно прямо в чате. Работает нестабильно, но для базовых задач подходит: например, проверить, есть ли на креативе узнаваемая знаменитость в нужном гео. Платная подписка не нужна.
➡️ Читайте на сайте: https://aff.top/blog/v-deepseek-dobavili-raspoznavanie-izobrazhenii
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek запустил бета-версию распознавания изображений — функция доступна бесплатно прямо в чате. Работает нестабильно, но для базовых задач подходит: например, проверить, есть ли на креативе узнаваемая знаменитость в нужном гео. Платная подписка не нужна.
➡️ Читайте на сайте: https://aff.top/blog/v-deepseek-dobavili-raspoznavanie-izobrazhenii
🧠 Ещё больше инсайтов → в канале AFF.top