12 ms·
Django REST framework 3.15.0
- alejoar 3y agoI 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.
- deleted 3y ago[deleted]
- hiAndrewQuinn 3y agoLearning 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/ https://djangoforbeginners.com/
- giovannibonetti 3y agoI 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 3y agoI 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 3y agoHaving 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 3y agoWill 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 3y agoEven 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 3y agoThe 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 3y agoYou 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 3y agoIf 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).
- 3y ago
- devnonymous 3y agoIMO, 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!
- pokepim 3y ago[dead]
- stavros 3y agoWhat magic does Django have?
- devnonymous 3y agoBy 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=fpas&ia=web https://duckduckgo.com/?q=deep+modules+John+Ousterhout&t=fpa...
- nijave 3y agoImo 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 3y agoEvery 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 3y agoIt’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 3y agoWhenever you have “there is complex business logic that determines how SQL clauses are chained together” the Django ORM is invaluable.
- tc08 3y agoAs 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 3y agoIs 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 3y agoIt 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.
- jonatron 3y agoI 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/ https://www.cdrf.co/ helps with the class inheritance tree.
- agumonkey 3y agoThey really should add these to the main docs website.
- notanormalnerd 3y agoWhich is obviously inspired by https://ccbv.co.uk/ 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 3y agoI don't think http://django-vanilla-views.org/ 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 3y agoI 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/ 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 3y agoThe 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).
- sebra 3y agoAs 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 3y agoDRF is horrible
- tgv 3y agoI 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 3y agoYou 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 3y agoI'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 3y agoBecause ... ?
- midtake 3y agoLast time I used Django Rest Framework the serializers were slow. Has this changed in recent years?
- Alex3917 3y agoNo, but you don’t need to use the built-in serializers. Just swap them out for Marshmallow.
- the__alchemist 3y agoThis implies using two library layers on top of Django's own syntax. At that point, `def serialize(self) -> dict:
- neilfrndes 3y agoNot 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 3y agoAs long as you load them with objects that don’t need future queries they are fine….
- tumidpandora 3y agoHobbyist 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 3y agoYou 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 3y agoI 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 3y agoIsn't the former basically a JsonResponse? https://docs.djangoproject.com/en/5.0/ref/request-response/#jsonresponse-objects https://docs.djangoproject.com/en/5.0/ref/request-response/#...
- the__alchemist 3y agoApparently; even better; ty! Edit: Did a drop-in replacement of JsonResponse; confirmed working.
- PrivateButts 3y agoI 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 3y agoCool 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 https://github.com/neuroforgede/nfcompose