Django *

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

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

В одном из проектов этот узел был собран так, первый платеж создается с capture=False, входящий webhook проверяется по IP, каждое событие сначала пишется в журнал, потом маршрутизируется в обработчик, capture подтверждается стабильным idempotence key, успешный платеж валидируется по сумме, валюте и metadata, а на случай расхождения остается отдельный ручной confirm, который умеет дочитать фактический статус из ЮKassa и синхронизировать локальную базу.

То есть задача тут не просто принять webhook, а построить платежный контур, которому можно верить.

Django, пожалуй, самый популярный фреймворк для разработки на Python. Да простят меня «питонисты» и «джависты», если я рискну сравнить важность этого фреймворка для Python c важностью Spring для Java.

Всем привет! Меня зовут Макс, я Lead Backend и автор YouTube‑канала PyLounge. 

Это третья часть мини‑серии о Django‑миграциях. В первой части мы готовились к миграциям и разбирались с конфликтами, во второй чинили типичные подводные камни. Если их не читали, то рекомендую начать именно с них, а затем вернуться сюда.

В этом же материале поговорим о самом интересном: что происходит, когда python manage.py migrate запускается в 17:30 в пятницу на проде, под 3k RPS и таблицей в 200 миллионов строк. 

Расскажу какие блокировки в PostgreSQL берёт каждая операция Django, что внутри atomic = False, как пишется правильный паттерн expand‑migrate‑contract, зачемнужны AddIndexConcurrently, AddConstraintNotValid, SeparateDatabaseAndState и как обновлять данные на больших таблицах.

P. S. примеры намеренно упрощены, чтобы влезли в статью и не задушили. В реальной жизни всё ещё хуже — но шаги те же.

P. S.S. При подготовки этого материала ни одна продовая база данных не пострадала. 

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

Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности.

То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила.

В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model, чтобы интерфейс знал, кто реально сгенерировал результат.

Я Михаил — создатель и главный разработчик системы вэб приложений. Второй участник проекта — Владимир — разработчик мобильных версий и ответственный за SEO оптимизацию.

Недавно я внедрил blue‑green деплой в проде. Реализация довольно простая и кастомная, но справляется со своей задачей на ура! Также сообщу, что используется обычный докер композ на виртуалке — возможно, кому‑то такой подход будет полезен.

Для фоновых процессов (воркеров)

В приложение добавляется специальный инфрастуктурный singleton класс с флагом is_accepting, и обертка на consumers. В каждом консьюмере перед обработкой проверяем этот флаг: если True — обрабатываем задачу, если False — переносим задачу на повторную обработку (например, в rabbitmq делаем сразу nack(requeue=true))

Каждый раз, когда начинаешь новый SaaS-проект на Django, первые две недели уходят на одно и то же. Сначала — кастомная модель пользователя с UUID вместо integer PK, потому что потом не переедешь. Потом JWT-аутентификация, настройка SimpleJWT, написание RegisterView, LoginView, LogoutView — всё это уже было в прошлом проекте, но лежит в другом репозитории и просто так не скопируешь. Дальше Docker Compose: сервисы web, db, redis, celery, celery-beat, flower — шесть штук, которые надо поднять и связать между собой. Потом разбираться с Celery, который в новой версии изменил синтаксис конфига. Stripe webhooks с идемпотентностью — отдельная история. Мультиарендность, роли, permissions — ещё неделя.

В итоге к первой рабочей фиче добираешься к концу третьей недели.

Добавь сюда ещё один нюанс: каждый раз это проект с немного другим стеком. Где-то Kafka вместо Redis, где-то allauth с самого начала, где-то биллинг на пользователя, а не на команду. Но ядро остаётся одним: каждый раз перед стартом ты тратишь одинаково одни и те же две недели. Вот это и хотелось исправить.

Я прошёл через это несколько раз и в какой-то момент решил, что хватит. Собрал Django SaaS boilerplate под названием Shipyard — не как набор сниппетов в Notion, а как полноценный, готовый к production репозиторий, который можно клонировать и сразу писать продуктовую логику.

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

Продолжаю делиться своим опытом использования Claude Code и пакета скилов GStack от CEO Y Combinator. Сегодня продемонстрирую насколько поддержка мультиязычного сайта на Django может быть простой.

Во многих fullstack-проектах на Next.js и Django авторизация разваливается в одном и том же месте. На фронте удобно использовать NextAuth, потому что он закрывает формы входа, OAuth, серверную сессию и клиентские хуки. На бэкенде хочется иметь обычный JWT-контур на Django REST Framework, чтобы защищать API, работать с access и refresh токенами и не привязывать бизнес-логику к фронту. В итоге часто получается неприятная схема: пользователь логинится через NextAuth, потом отдельно логинится в Django, потом где-то вручную перекладываются токены, а через пару недель вся эта связка начинает ломаться на refresh, logout и OAuth.

Что делаем. Пользователь проходит один вход на фронте, а дальше фронт уже работает с токенами Django как с единственным источником доступа к API. Без второй формы входа, без ручного хранения access token в localStorage, без отдельного костыля под Google OAuth.

Разберем рабочую схему, в которой NextAuth отвечает за пользовательскую сессию на фронте, а Django остается владельцем API-авторизации и выдает JWT. На credentials-входе NextAuth сразу получает access и refresh от Django. На Google OAuth фронт сначала пускает пользователя через провайдера, потом синхронизирует его с Django и тоже получает пару токенов. После этого все запросы идут через один axios-клиент, который сам подставляет access token, сам обновляет его через refresh и сам завершает сессию, если refresh уже недействителен.

Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.

Это была система управления розничной сетью: несколько филиалов, сотни тысяч записей о заказах, ежедневные отчёты по выручке и остаткам. На бумаге ничего страшного. На практике монолит на Django где бизнес-логика размазана по контроллерам так, что поменяй что-то одно и сломается три другого.

Первое, что я сделал: открыл EXPLAIN ANALYZE.

Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка python и инструментов Django, pytest, factory_boy.

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же core-разработчик фреймворка Litestar, пакета django-stubs и множества других пакетов для Django.

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

Если хотите похоливарить в коментах на тему того, какой фреймворк самый лучший и удобный – залетайте! Обсудим.

При запуске MVP считаем вначале не клики вообще, а деньги и время. Деньги потому, что до серьёзных вложений полезно быстро и по возможности бесплатно проверить, нужен ли проект рынку. Время потому, что его легко потратить не на сам MVP, а на подключение Яндекс.Метрики, Google Analytics, событий, воронок, отдельной базы и прочей обвязки. В итоге идея ещё не проверена, а вокруг неё уже начинает расти аналитическая система.

Рассмотрим простую схему с 1-2 быстрыми метрики, которые напрямую проверяют УТП или главный пользовательский сценарий. Пользователь нажал кнопку покупки. Начал создавать проект. Зарегистрировался. Перешёл в Telegram. Этого уже хватает, чтобы понять, работает ли сценарий и есть ли живой отклик.

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

Разберем именно такой вариант. Маленький Django-бэк один раз деплоится на простом хостинге, принимает события через пиксель, хранит их в SQLite и отдаёт статистику JSON-ответом. Дальше во всех новых фронтах меняются только названия event и src.

Особенно удобно это в тех случаях, когда фронт живёт на бесплатном или засыпающем хостинге. У free web services на Render сервис уходит в spin-down после 15 минут простоя, а файловая система там ephemeral, поэтому локальный SQLite для таких счётчиков работать не будет. В качестве простого примера отдельного маленького бэка можно использовать PythonAnywhere, где есть бесплатный аккаунт с одним web app. Но сама идея не привязана к этим площадкам и повторяется практически где угодно.

Я регулярно выкладываю посты в блог НормЦРМ. На двух языках: русском и английском.

Написал пост, придумал заголовок. Тут всё просто. А дальше неприятный процесс. С помощью ИИ перевести пост на английский — и перенести перевод в блог. А ещё сгенерировать мета-данные и og-данные (это для поисковиков и мессенджеров), тоже перевести их на английский и руками поставить в нужные поля.

Всё это занимает минуты, но такая работа раздражает. А пишу я довольно часто (публикация раз в пару дней). И решил сделать в интерфейсе одну кнопку, которая возьмёт на себя всю эту рутину. Решил — и сделал. Теперь в один клик переводится пост и генерируются все мета-данные.

Сейчас расскажу во всех деталях, как именно это реализовано. Вдруг вы тоже так захотите?

Django Rest Framework (DRF) - чуть ли не единственный фреймворк для разработки REST на базисе Django. Мой нарратив о Django в прошлой статье заключался в том, что это неповоротливый монолит, который абсолютно не следует best practices и не стремится к ним. Если вдруг вы не задумывались о том, как связаны DRF и Django, то вас может быть немного это удивит - никак. Их делали совершенно разные люди, но каким-то образом они сошлись в общей концепции: игнор хороших практик, перегруженные классы и магия, превращающая разработчика в гадалку.

СУБД PostgreSQL сейчас вероятно, является самым популярным бакендом для Django. К сожалению, у этой СУБД есть особенность - для построения индексов, она блокирует таблицу, и на время выпололнения индексирования, запись в эту таблицу оказывается недоступной, что приводит к частичной или полной неработоспособности приложения на время выполнения миграции, включающей в себя построение индекса.

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

Как решать эту проблему - описано в данной статье.

Вот что для этого понадобилось: бэкендеры — 2 штуки, фронтендер — 1 штука, дизайнер — 1 штука, мобильный разработчик — 1 штука, время — 2 учебных семестра.

Продолжаем рассказывать об интересных проектах студентов Контура. В этот раз речь пойдёт о приложении для интерактивного мониторинга белых акул по заказу Стэнфордского университета. 🦈 В статье ребята рассказали, какие возможности реализовали внутри приложения, какой стек технологий выбрали и что за сложности случились на фронтенде и бэкенде.

Я долго работал в коммерческом проекте в роли backend-разработчика с всемирно известным фреймворком Django, а также с его альтер эго - Django Rest Framework. Всегда кажется, что работать с чем-то многозвёздочном на GitHub - это кататься сыром в масле. На входе имеем: отличную документацию, отзывчивое сообщество, множество решений одной и той же проблемы, так как все уже (пред)решено...

Django ORM прячет SQL за красивым Python-интерфейсом. Пишешь User.objects.filter(active=True).order_by('name')[:10] — получаешь список пользователей. Круто. Но когда запросы тормозят или N+1 пожирает базу, приходится понимать, что вообще происходит.

Разберём внутренности QuerySet: почему он ленивый, как работает chaining, когда запрос реально выполняется, и чем select_related отличается от prefetch_related на уровне SQL.

Привет, Хабр!

Сегодня поговорим о том, как включать и выключать функциональность в Django, не разворачивая каждый раз новый деплой. В больших проектах эту задачу решают через feature flags, такие условные флажки , которые позволяют запускать скрытые возможности лишь для части пользователей или откатывать фичи, не выкатывая заново весь код. Если вы хотите поэтапно раскатать новую функцию, сделать A/B тест или просто спрятать недоделанный модуль за переключателем, вам сюда.