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 и менее лояльных партнёров.

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

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

7 ошибок в Python-скриптах, из-за которых они ломаются на реальных данных

Если скрипт работает на тестовом JSON, это ещё не значит, что он переживёт CSV от клиента, пустую строку или кривую кодировку.

— Нет проверок входа: функция сразу лезет в поля, не проверяя None, пустой список и типы.
— Ловят Exception на всё подряд и молча продолжают: баг прячется, а не исправляется.
— Смешивают парсинг, бизнес-логику и запись в файл в одном блоке: потом нечего тестировать.
— Полагаются на порядок ключей, формат даты и «всегда есть это поле».

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

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

$80 за FTD на СНГ — казино-оффер от ПОКЕРОК Partners

Ищете новый оффер для теста? Рассказываем, что предлагаем партнёрам:
• CPA $80 за FTD на все гео СНГ
• $100 к первой выплате для новых аффилиатов
• 5% по саб-реферальной программе
• прозрачная статистика в партнёрском кабинете
• поддержка личного менеджера

Принимаем различные источники: social, мессенджеры, YouTube / Twitch / Kick, SEO, PPC, in-app и медийный трафик.

В казино ПОКЕРОК также доступна GG99 — линейка из 20+ игр с RTP 99%, включая слоты, настольные игры, видеопокер и аркады. Это весомое преимущество для новых игроков в дополнение к приветственным бонусам.

И ещё один повод подключиться уже сейчас: 27 августа состоится Friendly Tournament для партнёров ПОКЕРОК Partners. Успейте подключиться до 25 августа, чтобы принять участие!

Присоединяйтесь к ПОКЕРОК Partners и начинайте зарабатывать на своём трафике уже сейчас!

Flask ломают не фреймворк, а невидимый хаос вокруг него

В Flask легко собрать «работает на локалке» за вечер, а потом месяц чинить побочные эффекты. Типовые ошибки всегда одни и те же: глобальные переменные для состояния, бизнес-логика в view-функциях, конфиг вперемешку с кодом.

Если проект больше пары эндпоинтов, сразу держите границы:
— routes только принимают запрос и возвращают ответ
— сервисы содержат правила и расчёты
— доступ к БД и внешним API вынесен в отдельные слои
— конфиг и секреты живут вне репозитория

Для Flask особенно важны application factory и blueprints. Первый убирает магию с импортами, вторые не дают разрастись одному файлу до состояния «всё в app.py». Ещё одна частая ловушка — создавать клиент БД или HTTP-сессию на каждый запрос без контроля жизненного цикла; это быстро бьёт по стабильности.

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

Flask ломается не на роутинге, а на мелочах вокруг приложения

За неделю в репах чаще всего всплывают не «сложные баги», а одни и те же промахи:
— держат глобальное состояние в модуле, а потом ловят гонки между запросами;
— тянут конфиг вручную по файлам, вместо одного объекта настроек;
— смешивают view, бизнес-логику и доступ к БД в одном обработчике.

У Flask сильная сторона — минимальный каркас. Но именно поэтому важно сразу разделить слои: route только принимает и возвращает, сервисы считают, репозитории читают и пишут. Как только логика расползается по handlers, тесты становятся дорогими, а любой рефакторинг превращается в лотерею.

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

Если нужен Flask-проект, который переживёт не один спринт, держите простое правило: приложение должно быть маленьким, а доменная логика — независимой от Flask. Тогда смена шаблонов, БД или точки входа не сносит весь код.

Starlette часто ломают не роуты, а мелкие ошибки вокруг ASGI

Starlette любят за минимализм: быстрые ответы, WebSocket, фоновые задачи, middleware. Но в бою чаще всего страдает не сам фреймворк, а обвязка вокруг него.

— Не смешивайте тяжёлую логику с endpoint: вынесите парсинг, валидацию и доступ к данным в отдельные функции.
— Не ждите чудес от sync-кода внутри async: блокирующие вызовы сразу бьют по задержкам и конкурентности.
— Не вешайте middleware «на всякий случай»: каждая прослойка добавляет стоимость на каждый запрос.
— Не игнорируйте lifespan: там удобно поднимать пул соединений, кэш и внешние клиенты, а не создавать их на каждый запрос.

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

Если нужен надёжный каркас, держите ручки тонкими, а бизнес-логику — отдельно. Тогда Starlette остаётся тем, чем и должен быть: быстрым серверным скелетом, а не местом, где живёт весь проект.

FastAPI ломается не на роутинге, а на неявных зависимостях и типах

Чаще всего проект начинает “тормозить” не из-за самого фреймворка, а из-за того, как в нём собирают сервисный слой. Если зависимость тянет БД, кэш и внешний API в одном вызове, тестировать и отлаживать это почти невозможно.

Держите базовый чек-лист:
— разделяйте endpoint, service и repository;
— выносите I/O в отдельные функции, а не в обработчик;
— для входа и выхода используйте pydantic-схемы, а не сырые dict;
— не смешивайте бизнес-логику с зависимостями через Depends, если это можно передать явно.

Ещё одна частая ошибка — считать, что async везде ускорит код. Если внутри синхронный драйвер, тяжёлый JSON или блокирующий SDK, event loop всё равно будет ждать. В таком месте лучше честно оставить sync-участок или вынести его в отдельный worker.

И последнее: держите OpenAPI и схемы ответа в порядке. Когда контракт не совпадает с реальным payload, интеграции ломаются тихо, а поиск причины занимает больше всего времени. Хороший FastAPI-проект читается не по количеству эндпоинтов, а по тому, насколько предсказуемо в нём проходят данные.