Its really awesome that this project continues to endure. The code base is top notch and the maintainers are committed to the highest level of quality.
DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.
Agreed, this is a top notch project. Excellent code, documentation and, above all, the concepts exhibited in the library are extremely well thought out.
To be perfectly honest I think the implementation is a lot better than some of the documentation. The tutorials can be pretty confusing or just plain broken for anyone without at least an intermediate proficiency in Django already. Perhaps the documentation should have messages recommending that developers get good at Django first.
Most of my experience with it has been great though, it's a very well built technology.
I think versatility and the absolutely easy on-ramp are Python's killer app. The 'absolute noob' can start writing simple python code after 5min of introduction (you can start using it like BASIC), while the 'senior dev' can still write python after years and isn't turned off or overly constrained by the language. (Yes, of course, warts exists, no language is perfect)
And regarding Django being the killer app: There are other people for which numpy/scipy is Python's killer app, for example.
I believe that both the Django Core team and Tom Christie (DRF author) have stated that they have no desire to see DRF brought into Django, as that would tie DRF updates to Django updates, which would potentially slow down DRF releases.
But as other people said, no idea if it was copied and pasted into the django codebase or rewritten from scratch.. but everything South did, I believe Django now does.
I'm really glad that ModelSerializer classes now require either fields or exclude. IMHO not requiring that before was one of the biggest weaknesses of the project, since it could easily lead to data being unintentionally exposed.
I know that's maybe not the most exciting change, but I think it's important that it be very obvious what the code does even if a person isn't an expert in a given technology, especially when there are privacy/security implications.
I love Python but I've never used Django -- I've always used Ruby on Rails since that's what I'm familiar with. Do you know of any resources I could use to get more comfortable with DRF (i.e. more complex than just the Quickstart tutorial [0])?
I learned it recently, the best tutorial on Django is right in the docs. The docs start you off with a tutorial for building a polling app that is really great for teaching the basics
The docs are amazing, probably because Django was created by journalists so they are really great at communicating things. It's not like most programming docs that leave you feeling lost and need to be supplemented with outside tutorials.
That said I'm new to programming so I supplemented the tutorial and instructions on the docs page with the one on the Django girls site.
Actually, DRF itself has a fairly comprehensive tutorial. You linked to the "quickstart" page, but if you click on the other tutorial links it goes into much greater depth.
If you want to focus on REST APIs with Django, DRF is pretty much required, and it's only a "pip3 install" away.
I flirted with switching to Rails (and did a lot of Code School courses and most of Michael Hart's Rails Tutorial), then realized I didn't have to limit myself to what comes with Django out-of-the-box.
'Tango with Django' is by far the best tutorial on Django that I've found (http://www.tangowithdjango.com/). It is well written and goes much deeper than other tutorials. It's depth is similar to the Rails Tutorial in RoR world.
Out of topic, I think the way DRF project funded is very interesting, i.e. public funded fulltime developer working on OSS. How many other similar successful OSS with such funding?
I think the business case is clear enough to make for a big project like REST framework. It's a relatively small investment per-company, but the relative payoff if we can hit a level that keeps it sustainable is huge.
Interesting, somehow this project didn't come onto my radar. I was just about to start using Flask to build a REST API for our Oracle database. Definitely checking this out instead.
There was a port of DRF for Flask, but it was not as mature and not as good. I went with Django mainly because of the included batteries and in particular DRF.
I was just always dissuaded from the size of Django, Flask is mininal, and gets up and running quicker for me. Coming from a lot of Express work, it just made more sense to me, but I'll be definitely diving into DRF for my new project.
I use flask for a few applications.. it works, but even in my cases:
Any sufficiently complicated flask application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of django.
For sites that are just a few endpoints, it's great. I use it on an application that uses redis+gearman to spawn docker containers on demand. django would have worked too, but I'm not using anything other than routing and templating.
On the other hand, I have an application that I built on flask that I needed to shift the timezone of the dates.
in django you change TIME_ZONE and you're done. My flask app I had to fix it all myself, it was a nightmare.
The size of the framework is really not relevant in the context of Python server-side development. You just import what you need and ignore what you don't.
For example, I develop single-page apps with Django+DRF and Ember, so I never use Django's template engine. If you really want to minimize your setup, you can even go into your settings.py file and turn off the middleware you don't need.
Put another way, it's not like client-side JavaScript where the entire framework is sent to the user's browser.
The admin is great, especially at the start of a project, when you want to look at and manipulate your data even if it isn't needed in the product you end up with.
The size is less relevant - you only use what you need.
The other main reason I chose Django for a particular project is the ease at which I can find experienced developers afterwards. Not that it really matters that much, Python being Python, but its easier to find someone with Django experience than one with Flask.
Not really. Because its python, its all Python devs. But if you want someone with specific Django experience, you'll find it easier to find than flask. Popularity wins and Django is popular (for a good reason)
Beware, having used Django, Pyramid, and Flask (in order of first use) I would highly recommend Flask over Django. Django is batteries included which can cause pain when trying to use different batteries. For me, SQL Alchemy > Django ORM for example.
But if your use case fits well within the Django ecosystem...then Django can be easier.
Yeh that's neat, but I feel like that is just going to cost me something to play. Also, there will be other databases tied into this project as well SQL Server, MySQL, and RethinkDB.
That's got a service-based architecture, and we were using it both on the server side (where we wrote explicit Core API schemes, rather than auto-generated) and on the client side (moving towards doing our inter-service communication using `coreapi`, rather than directly through `requests`.)
For us, the dynamic client libraries were a big win - the client code that you're working with becomes more meaningful and robust, as it's working with an application layer abstraction, rather than directly at a network layer.
I really love the django ORM, after your model are done you can create a really fast api with DRF, and if you want to try graphql/relay is possible with graphene https://github.com/graphql-python/graphene.
The documentation is great, but navigating it is a pain. Class names, methods and modules really should be links to where they are documented (because they are almost always documented). Search could also stand to improve, a lot.
That's not currently supported. We need recurring revenue rather than one-offs, so that's what I'm pushing for right now. Out of interest, is recurring something you'd consider if there was another lower-priced individual tier added?
I did fund your original kickstarter for DRF3 as a heavy DRF user at $job, and now might consider signing up as a recurring payment. Your code has saved me a lot of time and effort in my career, so thanks much sir!
Well Django is good for ORM, migration and admin. DRF gave a new opportunity to provide new web technology to this old framework but it's not enough.
The global stack is very heavy and it's very complicated to use Websocket.
I was fan of Django but for me the future is in framework like phienix: light stack, fast, secured and supporting current web technology. It's avoid you all the time loose to implement tornado/rabbitmq stuff.
my only blocker for migrating a legacy application to DRF is because it doesnt have support for nested routes (and I have to use a third party package).
I'm not really sure why a framework would take a position where something is important (and probably requested enough) to put it in the official documentation.... but not make it part of the core.
First of all, why can't you use an external package?
If all you want is URLs which look like "/api/people/morgante/comments/3000/" it's easy enough to construct those simply as standard viewsets. They're totally normal.
Because they are a core component of the library. Its a big part of the utility it offers. They assume someone looking to use it already knows enough django basics.
Just curious if someone could give the tldr version of this vs graphql. I'm familiar with django, but not the rest framework, and have a basic understanding of graphql but am not really sure how they compare.
This has very little to do with graphql. The DRF is to get a solid json api up and running quickly. The standard it ships with conforms to the http://jsonapi.org/ spec. Which came mostly from the Rails community and many projects built in different stacks conform to.
You could totally add a graphql endpoint to any api `/graphql?[your GQL query here]`. We're currently exploring adding that to our Django/DRF backend with one of these https://github.com/chentsulin/awesome-graphql#lib-py
This is true, and I love DRF but I find it unfortunate then that the concept of Serializer exists. Tom Christie essentially says that Serializers can and should be used outside of views (REST) to decouple and encapsulate business logic. He seems to believe models are database operations-only. This view is fine (e.g., data mapper) but then it seems the scope of DRF is beyond REST and should be part of core.
DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.