C Django Rest Framework мы все дальше от Бога

[SHK83]

Про slug надо было упомянуть, когда про регулярки в ендпоинтах писали

[dyadyaSerezha]

Если Django и его аналог для REST так плохи, почему я вижу много вакансий именно Django? Просто легаси?

[bbc_69]

Для самого загадка. Видимо, исторически так сложилось. Я так понимаю, Джанго - один из первый веб-фреймвороков и точно первый из популярных. Остальные делались с оглядкой на него и точным пониманием того, как делать НЕ надо.

[danilovmy]

Вообще-то для примера из раздела "Query параметры"

class ProductViewSet(viewsets.ModelViewSet):
    ...

    @action(detail=False, methods=['get'])
    def on_sale(self, *args, **kwargs)
        return self.list(*args, **kwargs)

А в примере раздела GET api/products/{product_name}

# Поле, по которому ищем в БД
# lookup_field = 'slug'

Потому, как это уже и так указано в ModelViewSet

Но не суть. Простим автору полное незнание парадигмы инструмента.

Но вот этого простить не могу: А где причитания про yasg и speacacular? А стоны про асинхронные представления, где они?

Пойду-ка я лучше перечитаю классику "Окей, Джанго, у меня к тебе несколько вопросов" от @kesn, там веселее.

[nutsdonuts]

Простим душность комментатора, но одно не простим, почему он не почитал статью внимательно, где сказано, что мне есть много еще о чем рассказать в контексте DRF и не хотелось бы раздувать статью в лонгрид

Рад, что на хабре есть "неповторимый ориганал", который можно перечитывать после мастер-класса в комментариях

[kesn]

Да ладно, Макс, тут тоже весело. В принципе-то автор правильно накидывает. Я когда начинал работать с дрф, тоже знатно офигел, были схожие чувства.

[Vertoletto]

DRF - наиболее известный, но не единственный инструмент для разработки REST API под Django. Есть Django Ninja, Tastypie, Restless и даже возможность работы на чистом Django через JSONResponse :)
А DRF как правило выбирают как оптимальный вариант с точки зрения экономики процесса разработки. Если она не сводится, то даже самый оптимальный и следующий best practices код не имеет смысла.

[jesov22427]

Сейчас наши ребята пилят отличную библиотеку для REST, советую взглянуть

https://github.com/wemake-services/django-modern-rest

[Iriskin01]

Я думаю, что все кто немного поработал с DRF приходят к пониманию, что все эти вьюсеты зло и не надо их использовать в сложном проекте потому что:

• одного сериалайзера, пермишен класса, кверисета не достаточно для всех ендпоинтов, и начинаются эти сопли с get_queryset, get_anything

• много ендпоинов в одном вьюсете начинают раздувать его до безобразия

• всратый роутинг

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

# categories_list.py
class CategoryListView(mixins.ListModelMixin, generics.GenericAPIView):
    serializer_class = ...
    required_permission = ...
    permission_classes = ...
    pagination_class = ...

    def get_queryset(self) -> QuerySet[Category]:
        ...

    def get(self, request: Request, *args, **kwargs) -> Response:
        return self.list(request, *args, **kwargs)


# categories_upsert.py
from services.business.categories import category_create, category_update


class CategoryUpsertView(UpsertView):
    serializer_class = ...
    required_permission = ...
    permission_classes = ...

    def get_queryset(self) -> QuerySet[Category]:
        return ...

    def perform_create(self, serializer) -> None:
        category_create(...)

    def perform_update(self, serializer) -> None:
        category_update(...)


# urls.py
path("categories/", views.CategoryListView.as_view(), name="categories_list"),  # noqa: E501
path("categories/create/", views.CategoryUpsertView.as_view(), name="category_create"),  # noqa: E501
path("categories/<int:pk>/set-active/", views.CategorySetActiveView.as_view(), name="category_set_active"),  # noqa: E501
path("categories/<int:pk>/update/", views.CategoryUpsertView.as_view(), name="category_update"),  # noqa: E501

Не нравятся сериалайзеры для моделей, они вполне могут работать без походов в базу если наследовать от базового Serializer и задавать поля явно. Так же и для формирования ответа можно передать в сериаоайзер не кверисет, а писок, не модель а словарь/датакласс

Конечно проблема, что библиотека предлагает сомнительные пути для написания кода из коробки, но пару раз вляпавшись понимаешь куда лезть не стоит, а если есть в команде кто-то кто может дать по рукам, так и вообще хорошо

[4youbluberry]

Я был очень приятно удивлен инициативностью выполнения запросов в алхимии после джанго, отложенные запросы в Джанго очень непонятные

[gimntut]

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

При таком подходе придётся забыть об автоматической генерации swagger. Придётся всё описывать отдельно.

[mr_crach]

Кажется, в парадигме DDD самое место Django в вспомогательном домене.