[HN Gopher] Django REST framework 3.15.0
___________________________________________________________________
Django REST framework 3.15.0
Author : cosmosgenius
Score : 131 points
Date : 2024-03-17 08:51 UTC (14 hours ago)
(HTM) web link (www.django-rest-framework.org)
(TXT) w3m dump (www.django-rest-framework.org)
| hiAndrewQuinn wrote:
| 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/
| giovannibonetti wrote:
| 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.
| egeozcan wrote:
| 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.
| giancarlostoro wrote:
| Having done both in my career I would pick either one
| depending on various factors but they both can get the job
| done.
|
| One edge of Python is its like the modern day Perl in terms
| of how many libraries you can use with it to get things done.
| It certainly feels that way anyway.
|
| On the other hand .NET has cool things Python barely
| scratches the surface on like MAUI and Blazor. Not to mention
| both MAUI and Blazor are directly supported by a major tech
| giant.
| blackhaj7 wrote:
| 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 wrote:
| 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.
| saddist0 wrote:
| 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.
| JonathanBeuys wrote:
| You talk about performance, but I think that is another point
| for PHP. In my experience, PHP handles the same requests
| faster.
|
| Yes, I could build everything from scratch myself in Python
| and have the same statelessnes as in PHP. But parsing
| headers, creating headers etc feels like it should be handled
| by a framework. In PHP, it is build right in.
|
| And if I would build it, it would talk to the webserver via
| CGI. But I think CGI is slow. For PHP, you have mod-php which
| is super fast.
| fulafel wrote:
| 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).
| JonathanBeuys wrote:
| Imports are also updated the moment you update the imported
| file.
|
| I'm not sure if PHP stores any compiled binary or byte-code
| at all. Maybe it compiles it all on each request. It's super
| fast though, even with tons of imports.
|
| My guess would be that it keeps compiled versions of each
| file in memory and on each request, it walks down the whole
| import path. And when it encounters a changed import, it
| compiles only that one.
|
| Would be cool if someone with more knowledge could shed a
| light on what is actually happening.
| dsego wrote:
| Afaik, PHP can have opcode caching enabled or disabled.
| JonathanBeuys wrote:
| True. I see a "Zend OPcache" section in my phpinfo().
|
| It says: Cache hits 4746528
| Cache misses 38875
|
| Both values go up every time I execute phpinfo().
|
| I wonder why. Shouldn't "Cache misses" only go up when a
| source file is changed?
| raziel2p wrote:
| AFAIK, before PHP even accesses opcache for bytecode, it
| checks the file's metadata (last modified, most likely).
| So an updated file might never trigger a cache hit _or_
| miss.
| JonathanBeuys wrote:
| If it does not access the opcache, against what is it
| checking the last modified date?
| alecsm wrote:
| If you're talking about importing third party dependencies,
| composer takes care of that.
| raziel2p wrote:
| In PHP, dependencies are just .php files just like your own
| code, it all works the same.
|
| PHP code is also typically far less complex than Python
| modules - modern PHP code consists of a single index.php with
| procedural code, and everything else is just class / function
| definitions, so there are no side effects.
| smashed wrote:
| Most major PHP frameworks like laravel, symfony, Drupal,
| Magento develops all kinds of complex caching layers to work
| around PHP's stateless 1 request/1 execution model,
| essentially poorly recreating shared application state you
| would get for free with a long running worker process.
|
| Python's import model is not without its flaws either, but at
| least you have a working application state, no need to fully
| initialize your app for every single request.
|
| For simple apps that are contained within a few files, PHP is
| hard to beat for simplicity and speed.
| hiAndrewQuinn wrote:
| 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 wrote:
| 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.
| nijave wrote:
| There's a fair bit of nuance and it really depends on the
| setup. You can run Python with CGI and execute once per
| request but it's much more common to use wsgi/asgi. Likewise,
| I think php-fpm is still pretty common which runs long
| running PHP processes.
| raverbashing wrote:
| You can just do this with Flask or other frameworks/servers
| that support auto-restart
|
| (yes I think some js frameworks also allow this)
| JonathanBeuys wrote:
| When a framework "supports auto-restart", that usually means
| it has its own webserver for development and the auto-restart
| is supported when you use that.
|
| I don't like having a different webserver in development and
| production.
| loloquwowndueo wrote:
| For Python, gunicorn is suitable for production and
| development use and has a --reload option to reload on
| changed files. This functionality is framework-independent.
| JonathanBeuys wrote:
| The way I understand the gunicord documentation, this has
| the same effect as if you set up a script which listens
| for file changes and restarts the server (or workers)
| every time a file changes.
|
| That's way less efficient compare to how PHP handles it.
|
| I don't want processes to be killed and new ones to be
| started every time I change a file.
|
| PHP does it the right way: Only when a request that
| touches outdated code hits the server is that outdated
| code reparsed. As long as you just edit files, it uses up
| no resources at all.
| loloquwowndueo wrote:
| I've never switched to the browser and reloaded the page
| fast enough to "beat" a gunicorn reload after editing a
| file. So I get not "wanting" a process restart but I
| don't get why it's such a big deal in a practical sense.
|
| But hey if using what you use does what you want, then
| you do you.
| devnonymous wrote:
| 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 wrote:
| What magic does Django have?
| devnonymous wrote:
| By magic I mean the complexity brought on by the heavy use of
| metaclasses, patterns employed via convention rather than
| enforced by code (implying that you have to read enough of
| the code before you understand the patterns) and other
| similar leaky abstractions.
|
| Don't get me wrong, I do think Django is one of those deep
| modules[1] where the interface makes it a pleasure to work
| with but the internals do need effort. Especially the ORM
| layer.
|
| [1] https://duckduckgo.com/?q=deep+modules+John+Ousterhout&t=
| fpa...
| nijave wrote:
| Imo there's a fair bit of complexity in request dispatch with
| sync/async interop, wsgi/asgi, channels. I think you end up
| with something like 10+ frames going through all these pieces
| before you hit the middlware.
| 7bit wrote:
| 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.
| ic_fly2 wrote:
| 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.
| btown wrote:
| Whenever you have "there is complex business logic that
| determines how SQL clauses are chained together" the Django
| ORM is invaluable.
| tc08 wrote:
| 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.
| stavros wrote:
| Is django-ninja maintained? I've always disliked DRF and
| liked FastAPI, so Ninja was a natural choice, but my team
| ended up moving away from it because of it being less popular
| than DRF.
| sebra wrote:
| It is very much maintained and got it's 1.0 release not
| long ago. Sadly there is a single guy doing all the work
| for Ninja so the tempo of releases varies. I also think
| there is quite a way to the stability of DRF and DRF's
| ecosystem. If you want permissions and throttling for
| example you'll have to use django-ninja-extra which is
| pretty much "DRF but its Ninja".
|
| For me personally I think the micro approach of Ninja /
| FastAPI is at odds with what I want out of DRF. I just want
| to make my crud stuff and not worry about implementing e.g.
| throttling, etc, on my own.
| boxed wrote:
| I think it's a bad idea to judge tech based on popularity.
| It just becomes a game of high school fashion drama,
| instead of getting work done.
|
| Also, I think the comparison is unfair due to the sheer age
| of DRF. Check out this graph: https://star-
| history.com/#encode/django-rest-framework&vital... Then
| click the "align timelines" and you see that ninja is more
| popular than DRF was at the same age.
| ghnws wrote:
| >I think it's a bad idea to judge tech based on
| popularity. It just becomes a game of high school fashion
| drama, instead of getting work done. I disagree. If one
| tool is way less popular, you risk it being discontinued.
| You do not want to start maintaining a web framework on
| top of your application nor do you want to rewrite your
| entire app.
| mchicken wrote:
| In my experience, it was decent for simple CRUD interfaces, but
| anything beyond that turned the development into a nightmare.
| notanormalnerd wrote:
| 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.
| jonatron wrote:
| 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.
| agumonkey wrote:
| They really should add these to the main docs website.
| notanormalnerd wrote:
| 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.
| jonatron wrote:
| I don't think http://django-vanilla-views.org/ ever really
| caught on, but it does show that ccbv.co.uk shouldn't have to
| exist. The DRF class tree is small enough to keep in your
| head once you've spent some time with it.
| techdragon wrote:
| I honestly only managed to get my mind wrapped around how
| class based views worked by studying Django Vanilla Views
| and Django Rest Framework... while I eventually learned and
| understood why the built in class based views are the way
| they are... in no small part thanks to https://ccbv.co.uk/
| ... but it was definitely more instructive to have a more
| simple class and mixin hierarchy that I could use, put
| breakpoints on, and fully get my head at... in order to get
| my mind around the very concept of class based views ...
| after that it all made a lot more sense.
| Nextgrid wrote:
| 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).
| eddd-ddde wrote:
| Not too long ago I finally ditched vscode for webstorm for my
| day to day work, and it's honestly fascinating how much I was
| missing before.
|
| The fact that you can't even have multiple windows in vscode
| for say your task output is wild to me.
|
| But Jetbrains refactoring tools is where it shines to me.
| sebra wrote:
| 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 :)
| v3ss0n wrote:
| DRF is horrible
| tgv wrote:
| 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.
| jonatron wrote:
| You have to know what DRF is good for, and what doesn't fit
| well with it. Because DRF is on top of Django (one layer not
| many layers), you can always fall back to a function that
| takes a request and returns a response. You can also fall
| back to SQL instead of the ORM.
| blactuary wrote:
| I've been using Django for about 5 years and I've never
| bothered with DRF or even the ORM. Pure SQL and function-
| based views works just fine
| theyinwhy wrote:
| Because ... ?
| alejoar wrote:
| 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.
| midtake wrote:
| Last time I used Django Rest Framework the serializers were slow.
| Has this changed in recent years?
| Alex3917 wrote:
| No, but you don't need to use the built-in serializers. Just
| swap them out for Marshmallow.
| the__alchemist wrote:
| This implies using two library layers on top of Django's own
| syntax. At that point, `def serialize(self) -> dict:
| neilfrndes wrote:
| Not sure why this is down voted, I use marshmallow serializes
| with DRF. Marshmallow serializes are more flexible and the
| learning curve isn't high.
| brianwawok wrote:
| As long as you load them with objects that don't need future
| queries they are fine....
| tumidpandora wrote:
| 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 wrote:
| 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.
| the__alchemist wrote:
| 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 wrote:
| Isn't the former basically a JsonResponse?
| https://docs.djangoproject.com/en/5.0/ref/request-response/#...
| the__alchemist wrote:
| Apparently; even better; ty!
|
| Edit: Did a drop-in replacement of JsonResponse; confirmed
| working.
| PrivateButts wrote:
| 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.
| ancieque wrote:
| 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
___________________________________________________________________
(page generated 2024-03-17 23:02 UTC)