Django *

В этой статье расскажу, как мы построили отдельный модуль управления корпоративными чатами и каналами на Django, PostgreSQL и Telethon. Без привязки к нашей внутренней инфраструктуре — только архитектура, технические решения и несколько выводов, которые могут пригодиться при решении похожей задачи.

Когда количество рабочих Telegram-чатов у нас приблизилось к сотне, выяснилось, что проблема уже не в добавлении одного человека в одну группу. Проблема — доказуемо выполнить десятки однотипных действий и не пропустить единственный чат. При этом не допустить утечку ресурсов (ведь кому-то на это всё понадобится тратить время, а новых или уволенных сотрудников может быть больше одного).

Нового сотрудника нужно добавить сразу в набор обязательных групп. Уволенного — вовремя исключить из всех чатов, включённых в корпоративную политику доступа, чтобы у него не сохранялась возможность наблюдать за внутренней деятельностью компании. Служебного бота тоже нужно добавить, а иногда сразу назначить администратором.

Обо всём этом в статье!

Привет! Меня зовут Андрей Нелюбин, я руководитель функции фронтенд-разработки.
В рамках проекта для заказчика требовалось доработать сценарий работы колл-центра: связать телефонию на Asterisk с операторским интерфейсом, где рядом со звонком доступны данные клиента, заказы, статусы и действия управления.

Для этого в 2022 году была реализована собственная прослойка поверх Asterisk: backend на Python/Django, обработка событий через Django Channels, WebSocket для передачи изменений в интерфейс и frontend на Vue. В статье расскажу, как устроили архитектуру решения, как обрабатывали события звонков, зачем понадобился BFF-слой на Django и почему в рабочей конфигурации аудио осталось в SIP-клиенте, а контекст и управление — в операторском интерфейсе

Django ORM умеет долго скрывать проблемы: лишние запросы, гонки при save(), затянувшиеся транзакции и выборки, которые незаметно съедают память.

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

Mermaid это текстовый формат описания диаграмм. В строках задаются тип схемы, узлы и связи. На выходе получается SVG. Формат подходит для API и базы данных. Код можно сгенерировать, проверить, сохранить, открыть повторно и отрендерить на клиенте.

В mermind/views.py добавлен 503, если ответ модели не начинается с валидной головы Mermaid. Без этой проверки запрос завершается успешно, ответ от модели приходит, но диаграмма не строится. В ответе остаются fenced-блоки, Markdown, строки с #, служебный текст и фрагменты до первой строки диаграммы.

В проекте собран полный серверный и клиентский контур. Генерация, очистка ответа, проверка, рендер, повторная правка, сохранение и библиотека.

Как извлекать Mermaid-код из ответа модели. Ответ сначала режется до fenced-блока. Потом проверяется первая строка.

Читатели хабра знают меня как автора статей о django. Например, в предыдущем посте я писал о том, как собирался переписывать django на async/await. Кстати, первые эксперименты подтвердили, что подход рабочий, и что django отлично поддаётся переписыванию. А также - что он хорошо расширяем и содержит код высокого качества.

Однако, я пришёл к выводу, что несмотря на эти достоинства, django сильно уступает Pony ORM, которая, в отличие от django и других ORM, ещё и спроектирована правильно - способом, дружественным к оптимизациям. Не случайно в статьях, которые есть о ней на хабре, её хвалят именно за производительность.

В этой статье речь пойдёт о Pony ORM, но не о фичах для пользователя, которых много (о которых можно узнать в этих видео 1, 2), а о её внутренней архитектуре.

Недавно я опубликовал на Хабре статью о небольшом пакете django-scroll-to-top, который добавляет кнопку «Наверх» в проекты на Django. Сам пакет решает довольно локальную задачу, но обсуждение под статьёй оказалось интереснее, чем я ожидал.

В комментариях возник вполне закономерный вопрос: насколько вообще подобным интерфейсным дополнениям место в стандартной Django Admin? Ведь каждое установленное приложение добавляет свои пункты в боковое меню, и со временем административная панель действительно может начать выглядеть перегруженной.

Один из комментариев заставил меня посмотреть на эту проблему немного под другим углом. В результате вместо долгого спора появился ещё один небольшой open-source-пакет — теперь уже для сворачивания групп приложений в боковой панели Django Admin.

В предыдущих статьях я рассказывал, как появился веб-дневник диабета на Django и как постепенно оптимизировалась его производительность. Проект начинался довольно типично: пользователь вводил показатели сахара, записывал приемы пищи и дозы инсулина, а система сохраняла их в базе данных и отображала на графиках.

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

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

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

Именно поэтому архитектура проекта получилась такой.

Осенью 2024 года я не планировал начинать новый проект. Тем более связанный с медициной.

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

Вскоре нас направили в детскую больницу, где после обследования поставили диагноз — сахарный диабет первого типа.

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

Параллельно с этим я заканчивал курс Python в Яндекс Практикуме. Днём — работа, вечером — обучение, ночью — медицинские статьи и клинические рекомендации. Не самый простой период, но именно тогда и появилась идея проекта, о котором пойдёт речь дальше.

Почему мы отказались от «AI в каждой кнопке» и зато встроили AES-GCM в детское приложение

Откуда вообще взялось MIO

MIO — это история про собственные родительские потребности, с которыми сталкиваешься, когда ребёнку исполняется 5 лет.

Family Vault - Ключи и envelope - E2E и что внутри

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

Кнопка «Наверх» — вещь настолько простая, что обычно её делают прямо в проекте: ссылка, немного CSS, пара строк JavaScript — готово.

Для одной страницы это нормально. Но потом проект растёт. Появляется мобильная версия, cookie-баннер, чат в углу, требования к контрасту, строгий CSP. Где-то нужно добавить кнопку ещё и в Django Admin. И тот самый маленький кусок кода начинает жить своей жизнью.

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

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

Так появился django-scroll-to-top.

В декабре 2025 года многие ведущие инженеры мира все-таки высказались вслух о том, о чём боялись даже думать: «Кажется, LLM пишет код лучше меня».

Фархан Тавар, руководитель инженерного направления Shopify (3000 инженеров, 10% мирового e-commerce), рассказал, как они к этому готовились — и что делать дальше. Спойлер: сокращать команду они не только не собираются, но и наняли уже 1000 интернов. Но обо всем – в статье

Разработка супераппа в одиночку. Рассказываю, как за 8 месяцев я создал платформу на связке Django и Vanilla JS, какие критические уязвимости контроля доступа (IDOR) обнаружил в WebSockets и как решил их на уровне асинхронного бэкенда.

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

Я сделал для этого два полностью независимых Django-пакета с открытым исходным кодом: django-consent-152fz для юридически значимых согласий и django-cookies-152fz для политики файлов cookie, категорий, подключённых сервисов и окна выбора. В статье покажу реальную модель данных, минимальное подключение и то, как устроены редакции, журнал событий и выгрузка данных.

Здравствуйте, дорогие читатели! Сегодня - ещё одна статья из рубрики джангологии.

Раньше я уже писал о своих идеях (1 и 2) о том, как сделать django асинхронным. Они основывались, вслед за sqlalchemy, на использовании гринлетов. Несмотря на то, что proof-of-concept был успешно получен, а трудностей - встречено меньше, чем ожидалось, я всё-таки отказался от этого подхода: во-первых, он уже применяется в sqlalchemy. Во-вторых, это ведёт к усложнению, и растёт так называемая test matrix - потому что поддерживается как синхронный случай, так и асинхронный. А simple, как мы знаем, is better than complex.

Так вот, я решил возобновить эти свои попытки, изменив подход на более радикальный. А именно, необратимо переписать django на async-only, сломав совместимость полностью. Для этого потребуется заменить в половине функций def на async def и добавив await при их вызове. Я уверен, что такой подход лучше.

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

Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.  

Разработчики часто сталкиваются с проблемой: сайт успешно протестировали на мастере, выкатили на прод, провели контрольное тестирование — вроде всё хорошо. Сайт работает пару месяцев — и вдруг приходит задача от SEO «увеличить скорость загрузки сайта» или «исправить просевшее количество баллов в PageSpeed». Причём ничего принципиально нового не добавляли, просто наполняли контентом.

Начинаем разбираться — и выясняется, что есть общая проблема, которая почти всегда повторяется. А именно — изображения. В статье расскажем, что с ними делать — как оказывается, проблема распространённая и до сих пор актуальная.

Платежный код обычно выглядит ровным ровно до первого реального сбоя. Пока платежи идут по ожидаемому сценарию, кажется, что достаточно создать оплату, дождаться вебхука и обновить локальный статус. Но как только вебхук приходит повторно, приходит позже нужного, прилетает от не того 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. При подготовки этого материала ни одна продовая база данных не пострадала.