django-rest-framework VS Dependency Injector

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.

dependency_injector: https://github.com/ets-labs/python-dependency-injector

One approach is to pass this config as a variable to every class it is required, which I dont prefer. Another option is to annotate the config class as singleton and create the config object at every place where I need them. I also came across this library called Dependency_Injector. https://python-dependency-injector.ets-labs.org/ This seems a bit heavy weight for my use case though. I am looking forward to know how other solve this problem

Dependency Injector