django-rest-framework VS django-crispy-forms

for those wishing to use http3 with a Python web framework, the ASGI hypercorn[1] currently supports it.

made a Django example last week with a sample client based on the examples from aioquic[2]: https://github.com/djstein/django-http3-example

this example also includes the first pass at async Django REST Framework using adrift[3] based on these GitHub issues:

- https://github.com/encode/django-rest-framework/pull/8617

- https://github.com/encode/django-rest-framework/issues/8496

sources

[1]: https://github.com/pgjones/hypercorn

[2]: https://github.com/aiortc/aioquic

[2]: https://github.com/em1208/adrf

Inspired by popular REST API frameworks like Django REST Framework and FastAPI, I wanted to create an alternative for Next.js, that will handle type-safe validation of your Next.js API routes using object-schema libraries like Zod and Yup and generate the OpenAPI specifications and Swagger UI straight out of your business logic. Another heavy inspiration for this project was tRPC and I wanted to extend it's functionality for REST APIs, specifically.

djangorestframework

Django REST Framework configuration + Swagger with drf-yasg.

Django REST framework is a great toolkit for building Web APIs. It is hugely popular and simplifies building REST APIs in Django, offering tooling for model serialization, registering routes and even adding support for authentication. In future projects, I would consider using it.

> Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).

Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a different network address to be a different service (think of mounting different apps or microservices behind different URLs, for example).

Also, I wouldn't say Django is CQRS--CQRS is more or less a different phrasing of "JSON-RPC", which "REST" has become.

> Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):

Eh, some people are highly allergic to any boilerplate, but like, the DRF example [0] has practically none.

That Elm video is interesting, but I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". There's just a lot of inherent complexity there, and my evidence is every mainstream ORM, plus all the "backend-as-a-service" products that are multi-1000s LOC. Then again I think SQL is a great (legendary, honestly) language and we should stop trying to replace it.

[0]: https://www.django-rest-framework.org/#example

+1 for Django. What I'd like to see even more is something that is on-par with Django Rest Framework. This library deals with so much that I had wished that existed in other frameworks in other languages. Viewsets, different parsers, auto-generated API docs, excellent validation guards, authentication and permissions, throttling, filtering, pagination, versioning, many many more, it's just an amazing piece of work.

We start with an empty Django project which we call babelbox_project and an empty app called babelbox. We use the django-crispy-forms package to style our forms with Bootstrap.

django-crispy-forms because the defaiçt forms are good for validation but bad at rendering html

django-crispy-forms - have to put this up again, amazing for rendering forms simply.

django-crispy-forms

Doc: https://django-crispy-forms.readthedocs.io/en/latest/ Source: https://github.com/django-crispy-forms/django-crispy-forms