Django REST framework 3.15.0

[hiAndrewQuinn]

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/

[egeozcan]

I have a very similar relationship with .NET MVC + EF. I suppose Django would win against it (them) by a mile in the "batteries included" battle but oh boy was I productive with it, especially with some jQuery and knockout.js for the frontend. I really felt like I could build anything CRUD with the tools I had (I was specialized in system integration) and I had the fortune of getting paid for it. Now even the smallest memory of some of the code I've written back then makes me cringe, but I learned a lot.

From those experiences you not only learn what to do, you get "what not to do" and "ah these parts are useful because of this" kind of information as well.

[giovannibonetti]

I felt the same thing when learning Rails through Railscasts. So much practical advice for building useful apps to fulfill customer's needs

A few years later I learned Elm and had a similar lightbulb moment, this time for front-end web development specifically.

[blackhaj7]

Will Vincents books were a turning point for me too despite never having been employed to write Python.

Learning to build stuff and the excellent explanations he gave are still something I refer back to now as a senior JS dev

[JonathanBeuys]

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.

[hiAndrewQuinn]

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.

[devnonymous]

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.

[saddist0]

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.

[fulafel]

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

[raverbashing]

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

(yes I think some js frameworks also allow this)

[sebra]

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

[jonatron]

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.

[notanormalnerd]

Which is obviously inspired by https://ccbv.co.uk/ which helps with the normal django class based views.

It really helped me find my way around the inheritance tree as well.

[Nextgrid]

The class inheritance tree problem is solvable with a proper IDE/editor setup that allows you to drill-down into implementations. In a properly configured PyCharm for example you can Cmd+Click on any symbol and see its implementation (and do so recursively).

[agumonkey]

They really should add these to the main docs website.

[7bit]

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.

[tc08]

As someone who has used DRF in many projects over a decade, I 100% agree. In my current project I’m using django-ninja which gives me the power of the Django ecosystem and ORM with the simplicity of FastAPI. This is the way.

[ic_fly2]

It’s true that Django and especially DRF feel a bit overkill. But for any app that does actual business the extra bits have often saved my bacon.

[notanormalnerd]

DRF does what it says on the tin. It is REST by the definition of it. Not a HTTP JSON API but strict REST. A object with CRUD as an API. Everything else is outside of scope and mostly reall hard to do.

That's why I rarely use DRF and either use function based views directly or use another library.

[mchicken]

In my experience, it was decent for simple CRUD interfaces, but anything beyond that turned the development into a nightmare.

[devnonymous]

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!

[stavros]

What magic does Django have?

[PrivateButts]

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.

[tumidpandora]

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!!

[eyelidlessness]

You might find it easier to do piecemeal at first. Start by identifying where you have a pure data dependency that’s currently doing a round trip to render HTML redundantly or unnecessarily, and think about whether it can be served as both HTML and pure data via content negotiation. If it can, then you have the flexibility to decouple that dependency at your leisure.

[alejoar]

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.

[the__alchemist]

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.

[jdboyd]

Isn't the former basically a JsonResponse? https://docs.djangoproject.com/en/5.0/ref/request-response/#...

[ancieque]

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

[midtake]

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

[Alex3917]

No, but you don’t need to use the built-in serializers. Just swap them out for Marshmallow.

[brianwawok]

As long as you load them with objects that don’t need future queries they are fine….

[v3ss0n]

DRF is horrible

[tgv]

I don't think one should write APIs in Django. It's layer upon layer upon layer on top of a framework that wants hierarchical models and views, and you have to bend backwards to put a slightly more complex data model in it, and then another time to write all the hooks to make it fit the API. It's like paint by numbers for software engineering.

[theyinwhy]

Because ... ?