Even though I prefer Python over PHP, for web projects, I'm probably down with PHP forever. Because it so nicely supports stateless request handling without long running processes.
In PHP, you can just throw a php file on a webserver and it works. To update, you just update the file. You don't have to restart anything.
On the dev machine, you can just have Vim in one window and Firefox in the other, change code, hit F5, and you see what you did.
I don't like having to run a code watching process which then recompiles the whole codebase every time I save a file.
As a long time Django and DRF user I'm really happy this release finally got out. If you look at the PRs being released some of them are years old. It's true that DRF is a mature and feature-complete framework but Django is still evolving slowly and DRF must keep up with that at the very minimum. Big thanks to the maintainers for getting it out!
Here are some of my hilights from this relase:
* Default on model gets sent to API docs
* Orderedict replaced by plain dicts everywhere - plain dicts are ordered in python since 3.6 so this is a welcome simplification
* Automatic support for UniqueConstraints in ModelSerializers - this is one of the places where DRF were lagging behind. I found myself using the deprecated unique_together just to not bother with writing validators on all my serializers
* There is a new router supporting path converters instead of regexp - Looking forward to trying this out! Also long overdue IMO as this came to Django in 2017 :)
I find it hard to criticize DRF, but one thing that could be added to the documentation is how to deal with M2M. Last time I tried a few different ways of doing it, and only two of them worked, then I had to figure out which way is better.
Also, https://www.cdrf.co/ helps with the class inheritance tree.
Every time I tried to add an API to a Django project by using DRF, I was surprised by the sheer complexity it introduced to get basic things working.
I don't mich like the strict and inflexible DRF approach.
But great that they keep continuing supporting the framework for the people that like and use it. Or just use it.
IMO, DRF is one of the few libraries that can be considered stable and complete. The code is well structured, without a whole lot of hidden magic under the hood (as compared to say Django itself), yet providing immense functionality. I've learnt some neat patterns from digging into the code while working with it
To the devs : well done an Congrats on the release!
I love DRF, but we don't really use it anymore for front to back communication. Too much working around the pure REST implementation to get anything done. However, we'll still throw it into our projects because the data folks love it. Easy way for them to shop for whatever data they want from the system.
Hobbyist dev here, love Django and it’s my go to for rapid prototyping and have built a couple web apps with it. I love the batteries included approach over flask and the ORM is simply amazing. I tried a couple times to use DFR but never really stuck with it, my reason was that my html templates have a lot of dependency on views and I just find the idea of using DRF to decouple front end and back end hard. Not a DRF limitation but mine alone. I might just back and revisit it again. Kudos and Best wishes to the team on the release!!
I love DRF and use it daily.
I just wish I didn't have to do code contortionism any time I need to support async (or resort to a third party like adrf).
I looks like DRF will never support async.
I like the automatic model serializers, but don't like the extra layer of syntax in views, ie different than normal Django. DRF's system can be replaced in many cases by these helper functions:
def return_json(msg: dict) -> HttpResponse:
return HttpResponse(json.dumps(msg), content_type="application/json")
def load_body(request: HttpRequest) -> dict:
return json.loads(request.body.decode("utf-8"))
Cool to see this.
I love DRF for CRUD apis. It just gets the job done and you can Focus on data modelling.
We built our data hub/data Integration solution on top of it. [1] It was a good choice.
By far the most extensible and overridable library I have worked with so far. Even when you need to ressort to hacks, they never seem to break when upgrading a Version.
Last time I used Django Rest Framework the serializers were slow. Has this changed in recent years?
DRF is horrible
Learning Django and the Django REST Framework by working through William S. Vincent's Django for Beginners [1], Django for APIs and Django for Professionals was a turning point in my career. I started to take myself seriously as a developer, not just an electrical engineering grad who happened to like coding.
Not SICP as a teen, not the Haskell Book, not The Art of Unix Programming, not A Philosophy of Software Design. Those are all fantastic books, but they were the wrong things to read for someone whose definition of "Keep It Simple, Stupid" was "never build anything at all and stay unemployed". Django got me to shut up and build.
And build I did, and most of it did and does suck, and that's okay. And then I got a job, not doing Django, but using the things I learned from actually building with Django every day. I owe Django a great deal, and I still think of the DRF as my favorite approach to building a "well-tempered", maintainable API, on a deadline.
[1]: https://djangoforbeginners.com/