Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Microsoft планирует вставлять рекламу в игры
➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry
🧠 Ещё больше инсайтов → в канале AFF.top
➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AffPapa! Клуб спящих бизнесменов! Потрачено!
This media is not supported in your browser
VIEW IN TELEGRAM
Совсем скоро запуск ШЕСТОГО проекта на RU GEO от создателей APEX, EVA, KUSH, BANDA и LEEBET!
Please open Telegram to view this post
VIEW IN TELEGRAM
Python-скрипт для продакшена: чек-лист перед запуском по cron
Скрипт, который «просто раз в час дергает API», быстро становится частью продукта. До первого таймаута, дубля в базе или молчаливого падения. Минимальный набор защиты лучше заложить сразу.
— конфиг только через env или отдельный файл, без токенов в коде;
— логируйте не только ошибку, но и входные параметры задачи, id сущности, время ответа;
— добавьте таймауты на HTTP, БД и внешние команды;
— делайте операции идемпотентными: повторный запуск не должен портить данные;
— храните lock-файл или используйте блокировку, если два запуска опасны.
Отдельно проверьте выходы из сценария.
Хороший признак: скрипт можно запустить руками на тестовом наборе, остановить посередине и безопасно повторить. Если это не так, перед cron рано. Совет: пишите маленький README рядом со скриптом — команда запуска, переменные, пример dry-run и где смотреть логи.
Скрипт, который «просто раз в час дергает API», быстро становится частью продукта. До первого таймаута, дубля в базе или молчаливого падения. Минимальный набор защиты лучше заложить сразу.
— конфиг только через env или отдельный файл, без токенов в коде;
— логируйте не только ошибку, но и входные параметры задачи, id сущности, время ответа;
— добавьте таймауты на HTTP, БД и внешние команды;
— делайте операции идемпотентными: повторный запуск не должен портить данные;
— храните lock-файл или используйте блокировку, если два запуска опасны.
Отдельно проверьте выходы из сценария.
sys.exit(1) для аварии, понятные коды возврата, запись последнего успешного шага. Если скрипт обрабатывает пачку, не падайте из-за одной плохой строки: складывайте ее в отдельный список и идите дальше.Хороший признак: скрипт можно запустить руками на тестовом наборе, остановить посередине и безопасно повторить. Если это не так, перед cron рано. Совет: пишите маленький README рядом со скриптом — команда запуска, переменные, пример dry-run и где смотреть логи.
Starlette ломают не роуты, а мелкие ошибки в middleware и ответах
Если Starlette кажется «слишком тонким», проблема обычно не в фреймворке, а в том, как его используют поверх ASGI. Тут важны три вещи: жизненный цикл приложения, порядок middleware и типы ответов.
• Startup/shutdown лучше держать для инициализации клиентов, пулов и кешей. Не делайте там тяжёлую бизнес-логику: при падении инициализации приложение должно падать сразу, а не «жить полуживым».
• Middleware ставьте от внешнего к внутреннему по смыслу: логирование, трейсинг, авторизация, потом уже доменная обработка. Иначе отладка превращается в угадайку.
• Для JSON и стриминга используйте разные Response-классы. Если всё завернуть в один универсальный ответ, легко потерять заголовки, кеширование или корректную передачу тела.
Есть наблюдение которое стоит проверить: большинство багов в Starlette появляются не в endpoint-функциях, а на границе — где вы читаете request body, прокидываете state и смешиваете sync/async.
Если нужен стабильный сервис, начните с дисциплины вокруг ASGI-границ: отдельный middleware для каждого слоя ответственности, явные Response-типы и минимум магии в startup.
Если Starlette кажется «слишком тонким», проблема обычно не в фреймворке, а в том, как его используют поверх ASGI. Тут важны три вещи: жизненный цикл приложения, порядок middleware и типы ответов.
• Startup/shutdown лучше держать для инициализации клиентов, пулов и кешей. Не делайте там тяжёлую бизнес-логику: при падении инициализации приложение должно падать сразу, а не «жить полуживым».
• Middleware ставьте от внешнего к внутреннему по смыслу: логирование, трейсинг, авторизация, потом уже доменная обработка. Иначе отладка превращается в угадайку.
• Для JSON и стриминга используйте разные Response-классы. Если всё завернуть в один универсальный ответ, легко потерять заголовки, кеширование или корректную передачу тела.
Есть наблюдение которое стоит проверить: большинство багов в Starlette появляются не в endpoint-функциях, а на границе — где вы читаете request body, прокидываете state и смешиваете sync/async.
Если нужен стабильный сервис, начните с дисциплины вокруг ASGI-границ: отдельный middleware для каждого слоя ответственности, явные Response-типы и минимум магии в startup.