Flask ломается не на роутинге, а на границе между приложением и скриптом

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

Держите три правила:
— создавайте приложение через фабрику, а не в модуле с роутами;
— выносите настройки в отдельный объект, без прямого чтения env в бизнес-логике;
— не тяните db/session/client в глобальную область, если их можно передать явно.

Для маленького сервиса Flask удобен именно тем, что в нём легко держать границу между HTTP-слоем и кодом домена. Маршрут должен принимать данные, вызывать функцию и отдавать ответ. Всё, что похоже на вычисления, парсинг, интеграции и очереди, лучше вынести в отдельные модули — тогда код можно переиспользовать и в CLI, и в воркере.

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

Pydantic ломают не типы, а границы входных данных

Если модель валится в рантайме, проблема обычно не в самой схеме, а в том, что в неё тащат всё подряд: raw JSON, формы, query params и внутренние dict без разделения слоёв. Для веба полезно держать три уровня: входной payload, нормализованную доменную модель и объект для ответа.

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

Отдельная ловушка — nested структуры. Если список объектов может быть частично грязным, ошибка в одном элементе не должна скрывать остальные. Лучше явно собирать ошибки и отдавать их в одном ответе, чем чинить данные молча.

Ещё одна полезная привычка: не использовать одну и ту же модель для create, update и response. Это почти всегда приводит к лишним optional-полям, странным default и утечке внутренних атрибутов в API.

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

asyncio ломается не в await, а в границах между I/O, CPU и cancellation

Если в проекте «всё асинхронно», это ещё не значит, что оно масштабируется. В реальности чаще всего путают три вещи: параллельность, конкурентность и неблокирующий I/O. asyncio хорошо работает там, где задачи ждут сеть, диск или таймеры. Как только в корутину попадает тяжёлая CPU-работа, event loop начинает задыхаться.

Есть 4 типовые ошибки:
— забыли вынести CPU-bound кусок в thread/process pool;
— сделали много await подряд там, где нужен gather();
— не закрыли клиент/сессию/соединение и получили утечки;
— игнорируют cancellation, а потом ловят «зависшие» фоновые задачи.

Отдельно проверьте точки входа. Если внутри корутины вызывается обычный блокирующий код — sleep, requests, синхронный ORM, файловые операции без ограничений — весь выигрыш от asyncio исчезает. Для внешних API, очередей и парсинга это особенно заметно: один блокирующий вызов может остановить десятки задач.

Хорошее правило: корутина должна либо ждать I/O, либо быстро делегировать тяжёлую работу наружу. Если это не так — перепишите участок, а не «добавляйте больше async».

Flask ломается не на маршрутах, а на том, как вы смешиваете слои

У Flask есть полезная ловушка: проект легко стартует как один файл, а потом тихо превращается в комок view-функций, SQL и логики авторизации. Если через месяц в код страшно заходить, проблема обычно не в фреймворке, а в отсутствии границ.

Рабочая схема для живого проекта:
— routes держат только HTTP-слой: принять запрос, провалидировать, вернуть ответ;
— service содержит бизнес-логику и не знает про request;
— repository общается с БД или внешним API;
— extensions и config инициализируются отдельно, а не прячутся внутри view.

Еще одна типовая ошибка — хранить состояние в глобальных переменных и надеяться, что «в проде не заметят». Flask сам по себе не спасает от гонок, если вы пишете в модульные переменные, кэшируете «на глаз» или создаете клиент БД в каждом обработчике.

Если нужен проект, который не развалится от второго разработчика, начните с app factory, явной конфигурации и одного правила: view не должен делать больше, чем оркестровать вызовы. Тогда Flask остается быстрым в разработке и не превращается в склад технического долга.

Scrapy ломается не на парсинге, а на мелочах вокруг него: 6 проверок

Scrapy часто считают “просто фреймворком для пауков”, но в проде он падает на одинаковых вещах. За неделю в репах обычно всплывают одни и те же ошибки: не тот selector, дубли, кривой пайплайн, таймауты и слишком жирные ответы от сайта.

— Сначала проверь, что ты выбираешь именно стабильный узел, а не случайный div внутри карточки.
— Дальше смотри на дедупликацию: canonical, query-параметры, пагинация и одинаковые ссылки с разным мусором в URL.
— Если данные “исчезают”, ищи проблему в item pipeline, а не в spider: там часто тихо режутся пустые поля и неожиданные типы.
— Для тяжёлых страниц включай ограничение concurrency и нормальный retry/backoff, иначе ты сам создаёшь себе бан.

Есть наблюдение которое стоит проверить: если Spider работает только на одной странице, почти всегда дело в предположении, что HTML одинаковый. В Scrapy это лечится не магией, а явной проверкой структуры ответа и отдельной логикой на каждый шаблон страницы.

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

Если Scrapy “вроде работает”, но результат плавает, начни с трёх вещей: структура ответа, дедуп, pipeline. Это экономит больше времени, чем любой красивый рефакторинг.

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

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

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

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

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

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

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

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

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

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

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

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

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

CTV fraud: 6 проверок, которые спасают бюджет от «умных» бот-стримов

CTV выглядит как релиз года для медиа, пока не начинаешь смотреть в логи. Там внезапно всплывают странные устройства, одинаковые сессии, пустые профили и просмотр без нормального сигнала о реальном экране. IVT в CTV часто маскируется под «качественный инвентарь», потому что экран большой, а вопросов мало.

Проверяйте не только охват, но и контекст доставки:
— device/app bundle: мусорные приложения и неожиданные связки;
— session length и повторяемость: одинаковые паттерны у сотен «зрителей»;
— гео и таймзоны: когда домохозяйство живёт в трёх странах сразу, это уже fraud;
— ad pod behavior: слишком ровное досмотренное видео без пауз и промахов;
— supply path: лишние реселлеры любят прятать невалидный трафик.

Отдельно смотрите на spoofing: подмена модели устройства, ОС, app-идентификатора и даже производителя. Для brand safety это не только про потерю денег, но и про риск оказаться рядом с сомнительным контентом, который в отчётах красиво замаскирован под premium reach.

Если у вас нет контроля на уровне supply path и верификации сигнала, CTV легко превращается в дорогую иллюзию. Начинайте с аномалий, режьте подозрительные связки и не верьте инвентарю на слово — ad fraud в CTV обычно улыбается шире всех. Может, конечно, ни хуя не взлетит, но проверять всё равно придётся.

Pydantic ломается не на моделях, а на границах входных данных

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

• Не тащите всю логику в validators: проверяйте типы и форму данных, а бизнес-правила оставляйте в сервисах.
• Используйте алиасы и явные названия полей, если JSON и код живут в разных мирах.
• Для вложенных объектов лучше несколько маленьких моделей, чем одна огромная простыня.
• Если поле необязательно, задайте понятное поведение по умолчанию, а не «магическое None».

Самая частая ошибка — воспринимать pydantic как замену доменной логике. Он хорошо отвечает на вопрос «данные вообще можно принять?», но не должен решать, можно ли их проводить дальше по процессу.

Ещё один полезный приём — отдельно смотреть на схемы для входа и выхода. В API это снижает сюрпризы: то, что клиент прислал, и то, что вы отдаёте, почти никогда не должны быть одной и той же моделью.

Если pydantic в проекте уже есть, проверьте не количество моделей, а то, где именно они стоят в цепочке. Правильная граница экономит часы дебага.

FastAPI ломают не роуты, а границы между схемами, логикой и БД

За неделю в репах: почти все проблемы в FastAPI начинаются не в async, а в архитектуре. Когда endpoint тянет ORM, валидирует вход, собирает бизнес-правило и еще форматирует ответ — проект быстро превращается в набор связанных функций.

Разделяйте слои сразу:
— router только принимает запрос и отдает ответ
— service держит бизнес-логику
— repository знает про БД
— schemas описывают контракт, а не внутренности модели

Есть наблюдение которое стоит проверить: чем меньше кода в обработчике, тем проще тестировать таймауты, ошибки и валидацию. Особенно если зависимости передаются через Depends, а не импортируются внутри функции. Тогда заменять реализацию в тестах и фоновых задачах становится заметно проще.

Еще одно правило: не смешивайте Pydantic-схемы и ORM-объекты в одном слое без необходимости. Схема для входа, схема для ответа, модель для хранения — это не бюрократия, а способ не ловить случайные изменения полей по всему проекту.

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

7 причин, почему Python-проект начинает тормозить раньше, чем кажется

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

— Слишком много мелких запросов к БД вместо одного нормального SELECT с join/prefetch.
— Циклы поверх ORM-объектов, где можно заранее собрать данные пачкой.
— Лишние преобразования JSON, datetime и строк в горячем пути.
— Синхронный I/O внутри async-кода: один блокирующий вызов съедает всю пользу от asyncio.

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

Ещё один частый провал — логика в views, handlers и CLI-скриптах, которую давно пора вынести в сервисный слой. Когда бизнес-правило размазано по файлам, его невозможно профилировать, тестировать и ускорять без побочных эффектов.

Если проект начинает проседать, не ищите магию: сначала профилируйте узкие места, потом режьте количество I/O, потом только оптимизируйте Python-код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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