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/

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"))

This avoids the cognitive overhead of layering another syntax on top of Django's own conventions.

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.

[1] https://github.com/neuroforgede/nfcompose

Last time I used Django Rest Framework the serializers were slow. Has this changed in recent years?

DRF is horrible

PHP is underrated, especially as a learning resource. I'm very surprised I only ever built something with vanilla PHP on the job a few months ago - and how fast I could go from idea to prototype.

There is a very natural learning progression to: First build apps that run purely locally; then build a few static websites, maybe starting with hand-crafted HTML and eventually using something like Hugo; then build a small dynamic website with vanilla PHP; then finally build something with a more complex framework, like Laravel or Django. Going upwards in these iterations I think would help a lot ofd newer devs internalize where the tradeoffs of inital complexity vs. future ease of development lands for them.

The differences you speak about arise due to the nature of their design. PHP was created for the web whereas web programming support in python wasn't part of the language design. When you speak about web programming in python, the seam between the language and the web is usually a wsgi/agsi layer. This is where all the things you mentioned come into play. There's a whole lot of benefit imo to using python over php beyond that seam.

The difference is striking the balance between developer's speed and performance. In case we don't want to reload everything and run from scratch, it's pretty easy to do with python too. But we "chose" to run it always and quick reload, so the requests aren't too slow [and scalable].

Rest of the things you mentioned are pretty same for Python as well.

If PHP doesn't recompile your script imports, how does the reload tracking work with dependencies? Or does it punt somehow (eg only reloads your script but not is imports)?

There are various implementations of this kind of autoreload system for Python but it always seems to come with compromises on semantics (different initialization order causes behaviour differences).

You can just do this with Flask or other frameworks/servers that support auto-restart

(yes I think some js frameworks also allow this)