django-rest-framework VS django-tastypie

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.

Other than DRF, TastyPie is the other REST API framework for Django I had used in the past.

For an API, if you have a backend like Django (which I admit has a solid learning curve) you can make quick APIs with addons like django rest framework, or tastypie. The most recent I saw was django-ninja, but I have yet to try that out. I think an ML / cookie cutter plugin would be pretty interesting to be honest. I'll keep a look out and see, but /u/halfourname is correct, the flexibility would have penalties. Usually they're very narrow in scope.