🕸️ Django Tip — ускоряй сложные запросы с помощью `only()` + `defer()`

В Django ORM часто делают Model.objects.all(), вытаскивая все поля модели. Но если таблица тяжёлая, это съедает кучу памяти и тормозит.

💡 Лайфхак: загружай только нужные поля:

# Вместо этого
users = User.objects.all()  

# Сделай так
users = User.objects.only("id", "username")  
А если нужно отложить подгрузку дорогих полей (например, JSON или TextField):

users = User.objects.defer("profile_data", "settings_blob")

🟢 Что это даёт

⚡ Сильно ускоряет SQL-запросы (SELECT только нужные столбцы).
📉 Экономит память, так как Django не держит ненужные данные.
🔄 Поля можно подгрузить позже — при первом обращении Django сделает отдельный запрос.

💡 Совет: комбинируй only() и defer() для тонкого контроля — так можно оптимизировать даже очень «тяжёлые» модели без переписывания логики.

🖥 rest-filters — фильтрационный бэкенд для Django REST framework

Что это:
Новый инструмент для фильтрации в DRF, который расширяет возможности стандартного django-filter.

Особенности
- Использует serializer-поля для разбора и валидации (без Django-форм и виджетов)
- Поддержка группировки фильтров для гибкой логики
- Constraint system — проверка взаимозависимостей между параметрами
- Вложенные фильтры (nested filters) для работы со сложными структурами


Последний релиз — v0.6.0 (21 августа 2025)
- Возможность указывать группу по умолчанию для всего FilterSet (в том числе глобально)
- Поддержка subgroups для более сложных связей между фильтрами
- Новый метод FilterSet.get_combinator() для динамического выбора способа объединения фильтров
- ⚠️ Breaking change: теперь Entry нельзя создавать без указания группы

Почему стоит попробовать
Если стандартные фильтры Django REST кажутся ограниченными, rest-filters даёт:
- фильтрацию через сериализаторы,
- сложные сценарии с группировками и вложенностью,
- гибкость и расширяемость.

🔗 Репозиторий: https://github.com/realsuayip/rest-filters

🔥 Как я пишу Django views

Автор предлагает использовать базовый класс Django View вместо generic class-based views (CBV) или function-based views (FBV). Такой подход даёт простоту и гибкость при работе с HTTP-запросами. Отказ от сложных миксинов и использование понятных вспомогательных методов делает код более читаемым и сопровождаемым, снижая когнитивную нагрузку на разработчика.

Ключевые идеи

- В Django есть два популярных способа писать views: FBV (функции) и CBV (классы, включая generic views).
- Generic CBV часто содержат слишком много "магии": базовые классы, миксины, переопределяемые методы — их трудно держать в голове.
- FBV наглядны, но при усложнении логики код превращается в большие конструкции if request.method == ....
- Автор выбирает компромисс: использовать базовый класс View.
- Код остаётся простым.
- Логика neatly разделяется по методам (`get`, post и др.).
- Неподдерживаемые методы автоматически возвращают 405 (Method Not Allowed).

Пример

Вместо функции с if request.method:

class CommentFormView(View):
    def get(self, request, post_id, *args, **kwargs):
        post = get_object_or_404(Post, pk=post_id)
        form = CommentForm()
        return TemplateResponse(request, "form.html", {"form": form, "post": post})

    def post(self, request, post_id, *args, **kwargs):
        post = get_object_or_404(Post, pk=post_id)
        form = CommentForm(data=request.POST)
        if form.is_valid():
            comment = form.save(commit=False)
            comment.post = post
            comment.save()
            return redirect(post)
        return TemplateResponse(request, "form.html", {"form": form, "post": post})

👉 Источник: https://loopwerk.io/articles/2025/django-views/

👩‍💻 django-cors-headers — Django-приложение для обработки заголовков Cross-Origin Resource Sharing (CORS)!

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

🌟 Инструмент позволяет гибко управлять настройками CORS, включая поддержку конкретных методов, заголовков и настроек безопасности. Например, вы можете настроить разрешение только для определённых доменов или включить временный доступ для локальной разработки. Однако важно понимать риски, связанные с CORS, поскольку неправильная конфигурация может открыть доступ к вашим данным для нежелательных источников.

🔐 Лицензия: MIT

🖥 Github

@python_job_interview

🖥 Как организовать архитектуру большого Python-проекта?

Разработка крупного Python-проекта требует продуманной архитектуры. Правильная структура кода упрощает развитие, тестирование и поддержку приложения.

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

Обсудим разделение системы на слои (domain, service, infrastructure), использование популярных шаблонов проектирования (Dependency Injection, Repository, Facade), организацию кода по модулям и пакетам, примеры структуры каталогов, работу с зависимостями и конфигурацией (Pydantic, dotenv), логгирование и мониторинг, обеспечение тестируемости, поддержку расширяемости и модульности.

Также приведем примеры кода и структуры каталогов, а в конце – общие советы и распространенные ошибки, которых следует избегать.

https://uproger.com/kak-organizovat-arhitekturu-bolshogo-python-proekta/

🖥 Django 6.0 вышел - крупное обновление фреймворка

Вышел Django 6.0, и это одно из самых насыщенных обновлений за последнее время. Релиз добавляет функциональность, которую разработчики долго закрывали сторонними библиотеками или кастомными решениями.

Что нового и действительно важно:

Поддержка template partials из коробки
Теперь Django умеет частичные шаблоны на уровне фреймворка. Это упрощает структуру HTML, повышает переиспользуемость и делает шаблоны чище и понятнее без лишних include-хаков.

Нативный фреймворк для фоновых задач
В Django появился встроенный механизм для background tasks. Для многих проектов это означает, что Celery или RQ больше не обязательны для базовых задач — отложенные и асинхронные операции можно реализовать стандартными средствами.

Встроенная система Content Security Policy (CSP)
Django 6.0 получил полноценную поддержку CSP. Это серьёзный шаг в сторону безопасности по умолчанию и защита от XSS и других атак без внешних middleware.

Современный email API с нормальной Unicode-поддержкой
Работа с email стала более предсказуемой и дружелюбной к Unicode, что особенно важно для международных проектов и сложных шаблонов писем.

Жизненный цикл версий
Django 5.2 больше не имеет mainstream-поддержки. Разработчикам рекомендуется переходить на 6.0, чтобы получать новые возможности, обновления безопасности и улучшения платформы.

Django продолжает двигаться в сторону «batteries included», но делает это аккуратно и прагматично. Django 6.0 снижает зависимость от внешних библиотек, усиливает безопасность и делает повседневную разработку заметно удобнее.

Это релиз, который стоит внимательно изучить и запланировать апгрейд.

https://www.djangoproject.com/weblog/2025/dec/03/django-60-released/

🖥 FastAPI для клиента: как должны выглядеть API-клиенты в Python

Python-сообщество отлично научилось делать API-серверы.
FastAPI / DRF дают идеальный опыт разработчика:
- типы
- валидация
- понятные эндпоинты
- документация по OpenAPI
- минимум рутины

Но есть проблема.

Серверы стали удобными и “правильными”, а вот клиентская сторона до сих пор часто выглядит как кустарщина.

Что часто встречается в проектах на базе python:
- везде раскиданы httpx.get/post
- URL собираются руками
- параметры и headers копируются по коду
- ответы парсятся вручную
- ошибки обрабатываются как попало
- нет нормальных типов и автодополнения

И именно тут часто появляется 80% проблем.
API может быть идеально спроектирован, но пользоваться им неудобно.

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

В итоге клиенты либо не генерируют вообще, либо генерируют и потом ненавидят.

API-клиенты должны быть сделаны как фреймворк.
Как FastAPI, только наоборот.

То есть ты описываешь клиент красиво и декларативно:
- функция описывает intent (что мы делаем)
- типы описывают контракт
- библиотека берёт на себя HTTP-рутину

Вместо кода “на коленке”
httpx.get("https://api.site.com/users/123")

Должно быть
get_user(123)

И дальше библиотека сама:
- соберёт URL
- подставит параметры
- сериализует запрос
- выполнит HTTP
- распарсит ответ
- кинет нормальную ошибку
- даст типы и автодополнение в IDE

Именно эту идею автор статье и продвигает (проект Clientele)
Сделать API-клиенты удобными, чистыми и типобезопасными
так же, как мы привыкли делать серверы

Проблема не в HTTP.
Проблема в том, что API-клиенты в Python до сих пор не стали “первоклассным кодом”.

А должны стать.

Подробности: paulwrites.software/articles/python-api-clients

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах.

Владение Docker - навык, который отличает новичка от профи,

Сегодня почти всё разворачивается в контейнерах.

Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает».

• как упаковывать проекты в контейнеры
• как поднимать целые системы за минуты
• как избегать типичных ошибок в продакшене
• как делать стабильные и повторяемые окружения
•в нем разобраны все возможные ошибки

Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня.

🎁 Скидка 40 процентов действует 48 часов

👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

✔️ Лови полезный Django-совет, который спасает продакшен чаще, чем кажется.

Никогда не делай тяжёлую логику в Django views.

Новички часто пихают всё прямо во view:

- бизнес-логику
- валидацию
- расчёты
- работу с БД
- интеграции

В итоге получается "божественная функция" на 200 строк, которую невозможно тестировать и поддерживать.

Правильный подход — разделять слои:

- View — только принимает запрос и отдаёт ответ
- Services / use-cases — бизнес-логика
- Models — работа с данными
- Serializers / Forms — валидация

Плохо:

def create_order(request):
    user = request.user
    items = request.data['items']
    total = 0
    for item in items:
        product = Product.objects.get(id=item['id'])
        total += product.price * item['qty']
    order = Order.objects.create(user=user, total=total)
    ...

Лучше:

# services/order_service.py
def create_order(user, items):
    total = calculate_total(items)
    return Order.objects.create(user=user, total=total)

# views.py
def create_order_view(request):
    order = create_order(request.user, request.data['items'])
    return Response({"id": order.id})

Почему это важно:

• проще тестировать

• код переиспользуется

• view не превращается в монстра

• легче менять логику, не трогая API

Django не заставляет делать так, но большие проекты без этого долго не живут.

🖥 Большинство “парсеров” умирают через 2 дня.
Ты научишься делать те, которые живут в проде.

Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:

• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов

Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.

В итоге ты сможешь:

• забирать данные для своих проектов
• автоматизировать чужую рутину
• делать инструменты для аналитики
• брать коммерческие заказы на сбор данных

Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.

🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/