Полтора года назад я написал о своём подходе к структуре FastAPI-приложений. С тех пор два крупных проекта, production и несколько архитектурных граблей заставили меня многое пересмотреть. В этой статье расскажу, что изменилось и какие решения действительно упростили мне разработку.
Привет, Хабр! Меня зовут Семён, я разработчик приложений в экосистеме ИТ-продуктов «Лукоморье». До этого я работал дежурным инженером у телеком-оператора: принимал звонки, регистрировал аварии и раскладывал их по пяти Excel-таблицам. В плохие дни через двух операторов проходило до сотни инцидентов, а раз в месяц кто-то тратил полдня, чтобы собрать из этого зоопарка один отчёт для руководства.
Я захотел облегчить жизнь себе и коллегам и решил собрать приложение, которое снимет этот хаос: два месяца по вечерам учил Django, разбирался с миграциями и собирал интерфейс с нуля методом проб и ошибок. До минимально рабочего состояния проект я довёл, но работы оставалось ещё много.
Потом я сменил работу, а задача меня догнала: уже в «Лукоморье» мне прилетело ТЗ на похожую учётную систему, только для диспетчерской службы из другого региона. На этот раз я собрал работающую систему за неделю, не написав ни строчки кода.
Под катом расскажу, как это было, и сравню разные пути для достижения одной и той же задачи.
Как быть востребованным Python разработчиком? Какие технологии нужно знать, чтобы легко найти работу? Какие библиотеки и фреймворки уходят в закат и перестают пользоваться популярностью? На все эти вопросы вы получите ответ в этой статье.
Цель статьи: развеять мифы относительно реального применения различных технологий, библиотек и фреймворков в коммерческой Python разработке. После чтения статьи вы научитесь принимать верные решения относительно изучения той или иной технологии, чтобы всегда оставаться востребованным разработчиком.
Последние 3 года я веду свой блог и активно общаюсь с Python разработчиками. И это помогает мне делать выводы относительно рынка труда более рационально, чем я делал в начале своей карьеры. Надеюсь, что этот материал даст тебе, дорогой читатель, пищу для размышления.
В этой статье я часто упоминаю слово «актуальность». Под актуальностью я имею в виду, что конкретная технология используется достаточно большим количеством разработчиков.
Сегодня мы будем говорить преимущественно о таких гигантах, как Django, FastAPI и Flask, а также затронем не менее важные библиотеки: для работы с базами данных, тестирования, сборки проектов. Поговорим о таких противостояниях, как uv vs poetry, pytest vs unittest и других. В общем, будет интересно. Усаживайтесь поудобнее и погнали!
Вы, скорее всего, встречались с кардинально противоположными мнениями: "Django умер, да здравствует FastAPI", "Сейчас на FastAPI уже не пишут, встречай LiteStar", "Вообще на FastAPI особо ничего не пишем, только на Django".
В этой статье мы рассмотрим, какие есть типы сервисов для запуска проектов на Python. А в частности, различных админ-панелей, сайтов и веб-приложений на Django. И на что обратить внимание при выборе сервиса для хостинга Django-приложений.
Начнем с того, что Django проекту не подойдет хостинг статических сайтов и нужен именно сервис, поддерживающий работу backend-кода. И такие сервисы бывают очень разные и со своими особенностями.
В этой статье расскажу, как мы построили отдельный модуль управления корпоративными чатами и каналами на 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-блока. Потом проверяется первая строка.
Дорогие читатели, сегодня я расскажу о Pony ORM, которая во многих отношениях должна быть примером для других 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, категорий, подключённых сервисов и окна выбора. В статье покажу реальную модель данных, минимальное подключение и то, как устроены редакции, журнал событий и выгрузка данных.
Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.
Разработчики часто сталкиваются с проблемой: сайт успешно протестировали на мастере, выкатили на прод, провели контрольное тестирование — вроде всё хорошо. Сайт работает пару месяцев — и вдруг приходит задача от SEO «увеличить скорость загрузки сайта» или «исправить просевшее количество баллов в PageSpeed». Причём ничего принципиально нового не добавляли, просто наполняли контентом.
Начинаем разбираться — и выясняется, что есть общая проблема, которая почти всегда повторяется. А именно — изображения. В статье расскажем, что с ними делать — как оказывается, проблема распространённая и до сих пор актуальная.
