
Django REST framework 3 - tomchristie
https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3
======
junkmob
I've never understood why people like this framework so much. It's not that
flexible. If you want to customize your API in specific ways ( ordering,
nested resources, validation ), then you will undoubtedly just write your own
CBV(s).

After writing your own CBV(s) for awhile, you will either love that solution
or hate it and look for something more flexible and out-of-the-box.

For many of the things that Django REST framework version 3 is attempting to
solve there is already an awesome alternative to it and TastyPie called
Conduit. I highly recommend people give it a shot, since it's pretty modular.
It also presents a different alternative to Function and Class-Based views:

[http://django-conduit.readthedocs.org/en/latest/](http://django-
conduit.readthedocs.org/en/latest/)

~~~
findjashua
Flask-Restless has quickly become my favorite REST framework: [http://flask-
restless.readthedocs.org/en/latest/](http://flask-
restless.readthedocs.org/en/latest/)

~~~
Spiritus
Not really applicable to Django, is it?

~~~
parham
Same could be said about Django and APIs!

~~~
kyllo
Good point, but my impression of this tool is that it's more intended for
quickly tacking an external API onto an existing Django app, and not so much
for building an internal API for a client-side MVC app (Angular/Ember/Backbone
etc). It can certainly be used for that too, but Django is kind of overkill
for that use case, and a lighter-weight framework like Flask with a REST
plugin like Restless and (optionally) an ORM plugin like SQLAlchemy is
probably sufficient.

~~~
parham
My thought too but if your data is complex you should consider building an API
first using an ORM more powerful than Django's (e.g. SQLAlchemy) then use
Django to handle users and then allow your users to access the API directly
via signed requests or something... that way you get good performance without
network/Django ORM overhead.

~~~
lumpypua
I prefer SQLAlchemy, but it definitely has just as much overhead as django's
ORM. This is just a microbenchmark, but notice how when frameworks are making
raw DB queries they stomp the ones using ORM:

[http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query&l=1kw)

Looking at only python frameworks using ORM, Flask with SQLA hits 85% of the
requests/sec of Django using pypy, and only 73% on stock python. Django has
decently lower latency as well (450ms django, 550ms flask pypy, 600ms flask
stock python):

[http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query&l=1kw&o=1)

Really, if performance matters at all and you want an ORM use Java. The
fastest python solution using an ORM is a tenth as fast as the Java solutions,
with literally 10x the latency. :P Flask making raw db queries gets within 2x
of this, as does bottle.

[http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query&o=3)

~~~
wfn
These numbers are somewhat misleading, and the phrasing may confuse people.

> _The fastest python solution using an ORM is a tenth as fast as the Java
> solutions_

This _may_ be true if your bottleneck is the ORM in the first place (this is
relatively easily verifiable by running a profiler on your python program,
comparing the results against (e.g.) EXPLAIN ANALYZE output, etc.)

I run a service with a decently-sized database (over 100G); so far all the
bottlenecks were at the "query execution in the DB" level. I use lower-level
SQLAlchemy primitives to form the queries, and check the resulting raw SQL
against the raw SQL queries that I had designed for the DB before. If you know
what you're doing, SQLAlchemy will know, too.

Use cases and situations vary. But the way you phrase those particular
benchmarking results is somewhat misleading.

------
rectangletangle
As someone who is almost done with a fairly large personal project that's
built on top of the REST framework (~8,000 lines of Python). I gotta say it's
an awesome library. Whenever I find bugs, someone on GitHub is always ahead of
me. I've been using it with Python 3, and so far I've had no 3 specific issues
or bugs. I especially like the way DRF handles permissions and throttling.
It's quick and easy to switch out the permissions on any given view. Features
like the built-in throttle classes, and search filters are very convenient.
The thorough documentation, and browse-able API are also really nice. My only
real suggestion would be to break up some of the larger code blocks, and add
more hooks. This would make the framework even more flexible than it already
is.

------
SEJeff
I'll be donating to this for sure when I get home. This software is hands down
the cleanest, best structured, and nicest to use "framework" to build REST-ful
services in python.

I've used piston, tastypie, and DRF. It is the best of all 3 hands down.

~~~
HorizonXP
I'm going to as well. I wish there were still some £250 level rewards, as I'd
love to donate at that level. £1000 is a little rich for me this month, maybe
next! Might have to go in at the £100 level.

~~~
tomchristie
Hiya, I've just removed the limits on the higher levels of backing. See the
'Day 1 - Funded!' update here...
[https://www.kickstarter.com/projects/tomchristie/django-
rest...](https://www.kickstarter.com/projects/tomchristie/django-rest-
framework-3/posts/917891) \- There's been so much support that it just seems
unnecessarily restrictive.

~~~
HorizonXP
Awesome. Just backed it, and I see you've blown past the stretch goals.
Excited to see where you take this!

------
alphonse23
I calculated his basic salary, if he's asking for £4,378 for two days worth of
work per week for 6 months, that means he make £xx,xxx per 6 months... Man, I
wish he was making more period. This guy no doubt deserves more!

~~~
vially
Actually for the base goal of £4,000 he's guaranteeing two days a week for 2
months. The £12,000 stretch goal has to be reached for two days a week for 6
months. But still, he definitely deserves more.

------
parham
Django isn't built to be the main backend for an API, I've previously used
Tastypie and it's just not flexible enough, you should really consider using
Flask if you're planning to go API first.

~~~
gtaylor
It can be used as the main backend for an API just fine. It's also very easy
to override just about every piece of what DRF offers. This is pure,
unsubstantiated, subjective FUD.

Use the tool that you are most comfortable with, change it up if/when you get
big or busy enough to have to. There are some _huge_ sites running Django/DRF
successfully.

~~~
parham
Well it really depends on the data you have. It can easily be substantiated,
it's like saying I want to compete in F1 let me put the biggest engine in this
tanker truck, in other words do you need most of Django's layers for an API?
That's why I said if you're "planning to go API first" (Note: I love Django
for building sites not APIs)

~~~
gtaylor
This analogy really isn't useful at all. You aren't ever going to use 100% of
every tool your site is built on, and there's no shame in that. If you don't
end up using everything that Django does, no big deal.

There are some incredibly large sites with rich APIs that run Django very
successfully, so I'm thinking that this is all some pretty subjective
generalization that is of limited use.

------
msane
I'll put $50 into this if a feature of version 3 is supporting an optional
serializer / renderer that follows the "JSON API" spec
([http://jsonapi.org/](http://jsonapi.org/)), to support output similar to
rails' ActiveModelSerializers.

Anyone working with EmberJS would find this desirable because that is the
default format of API it expects.

------
falcolas
How does this compare to, say, Tastypie?

~~~
pjam
I used both for almost a year and while I really enjoyed working with
tastypie, I found Django Rest Framework to be even better.

\- I think Rest Framework's documentation is way better than tastypie's.

\- I found tastypie's source code to be overly complicated, while DRF was a
little bit better

\- The browsable API is really nice

\- I love DRF's API, such a Class Based Views, it felt like the continuation
of Django, instead of a complete new thing.

~~~
kyllo
It also (correctly IMO) uses headers to specify format rather than the client
needing to append stuff like _?format=json_ to the URL.

~~~
niels
Django Tastypie does that as well.

------
gomesnayagam
we use cyclone based eco-system, it is completely at your hand, we love that
extensibility.

------
gtaylor
Wish this wouldn't have been yanked off the front page!

~~~
dang
"Yanked" suggests human intervention. That's not what happened. It set off the
voting ring detector.

Edit: we turned the penalty off.

~~~
andybak
I wonder in this case whether it was a false positive. Lots of people want to
support a project like this and it's fairly natural to email people and tell
them that the link has been posted.

The only reason I _don 't_ do that any more is that someone told me about the
voting ring detector.

~~~
TylerE
Isn't that basically vote ringing?

~~~
pbreit
Communicating about an appealing topic shouldn't be so detrimental.

~~~
dang
Every voting ring considers its topic singularly appealing.

This is a hard problem and there are tradeoffs.

~~~
TylerE
What about allowing users (Maybe only those with more than x000 karma) to
downvote links?

~~~
dang
I doubt that we'll introduce story downvoting; at least not without a good
reason. Users can already flag stories that shouldn't be on the front page.

