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:
Django Rest Framework for us - http://ansible.com - was easier to customize and also easier to graft in custom auth. One of the major tastiepie problems we had - that maybe everybody doesn't have, was how to be able to make collections hang off REST resources.
The greatest feature by far is the API browser, which in DJRF 2 (I have no sense of what's in the 3rd version) is pretty amazing and a great way for people to learn about an API.
Less automagic made it much more flexible for us, while the API browser is just amazing in a end-user demo. It's my favorite feature, though I also like the serializer system.
Been writing a Django-based API-heavy app and it still feels very Django. DRF fits the ORM like a glove and there's a Django way of doing things that runs throughout. Models ≈ ModelForms ≈ ModelSerializers ≈ ViewSets ≈ ModelAdmin. Certainly never feels like I'm fighting the framework(s).
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.
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.
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:
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):
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.
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.
I wasn't refering to performance, but the queries you could do. If performance was an issue and the ORM was the bottle neck then I would use raw SQL and scrap the ORM altogether. Thanks for this benchmarks though good to know that info! :)
Edit: The overhead thing was a secondary point my main point was handling data.
Depends on your data, if you don't need joins/complex queries Django indeed is a great framework, though if an API is all you need a lighter framework might be worth looking into.
Django's ORM seems to be one of the areas they're consistently improving upon. Sure it's not SQLAlchemy. But SQLAlchemy is just an ORM, while Django is quite a bit more. Though I really love how SQLAlchemy separates it's core from the higher-level ORM.
Looks interesting, might port one of my tastypie projects to it.
However I'm very concerned about the author's inactivity. Tastypie has gone unmaintained several times for a long time. It looks like restless is headed that way as well. Concerning.
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.
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.
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.
"Best structured" is definitely true - part of the reason we can use it to power all the new Eventbrite APIs is because we can easily remove one or two pieces and swap in our own without breaking the rest. Makes my life a lot easier!
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!
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.
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.
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.
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)
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.
Well Flask is just the "glue" the real thing I like is its flexibility, which allows you to use tools that fit your needs, which for handling data SQLAlchemy blows Django's ORM out of the water. Don't get me wrong I love Django and I do use it a lot for websites but for handling data... it's restrictive to say the least.
It doesn't blow Django's ORM out of the water. It provides some extra functionality for doing the more unusual queries using the ORM, but all of those things are achievable in a terse, neat fashion Django by plugging in raw SQL into the gaps.
There's no real productivity boost between the two in my experience. Those holes in Django's ORM that need to be plugged by raw SQL aren't all that common anyhow. The VAST majority of SQL queries you will need the Django ORM can handle.
In projects I've worked on that don't do weird, strange or bad things with the database (e.g. ignoring foreign keys), the total number of custom, raw SQL queries has been between 5 and 20. Using an ORM for them instead wouldn't have saved more than a couple of lines of code total, if that.
What you DO get with Django's ORM that you don't with SQL Alchemy is the benefit of integration with all of the other django tools and modules - that saves you having to write a TON of code.
Well it's really hard to sell SQLAlchemy when you have never used it (I'm assuming, correct me if I'm wrong), read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old).
For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. Indeed for a website Django is my preferred tool too. Although in a project where I know the API is the core I would choose something lighter weight (using flask in my current project but learning from comments here Pyramid is something to look into too) and then build the portal in Django, handle user authentication there and allow access to the authenticated users to the API via requests signed in Django or direct access via API keys. In my experience it's the fastest/most flexible approach in terms of dev.
That's not a full comparison. It actually doesn't even touch on some of the advantages to using SQLAlchemy (i.e. in the more complex queries). It even says this at the bottom. Did you see that?
>For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment.
So now APIs don't require integration work? When I build ANYTHING I want to be able to have as large an ecosystem of libraries to pull from as possible because it will save me from writing unnecessary code and reinventing the wheel. First thing I do before building anything is to check on pypi to see if somebody wrote it first.
Too many junior developers make the mistake of thinking that their problem, project or app is somehow a unique snowflake and end up reinventing the wheel because they had no idea the wheel existed. Semi-experienced developers will still make this mistake by making bad architectural decisions in the name of flexibility or performance that end up locking them out of library ecosystems that means they are forced to reinvent the wheel even when they know it exists.
Being an experienced architect means (among many other things) knowing when to make the trade off between not railroading your code unnecessarily and standardizing it enough to let you use the vast array of free libraries out there.
>Although in a project where I know the API is the core I would choose something lighter weight
It's a myth that Django is heavy weight. You can make a django app with about 10 lines of code in one file using just the URL router if you really want to. Each one of the components can be swapped out nearly seamlessly exactly like with Flask.
You might not want to use it because it's slow, however, but flask will be too.
> That's not a full comparison. It actually doesn't even touch on some of the advantages to using SQLAlchemy (i.e. in the more complex queries). It even says this at the bottom. Did you see that?
Well those are most of the comparisons that could be made, from the top of my head I can't think of any other features that the two share.
> Too many junior developers make the mistake of thinking that their problem, project or app is somehow a unique snowflake and end up reinventing the wheel because they had no idea the wheel existed. Semi-experienced developers will still make this mistake by making bad architectural decisions in the name of flexibility or performance that end up locking them out of library ecosystems that means they are forced to reinvent the wheel even when they know it exists.
Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point.
> It's a myth that Django is heavy weight.
I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers
Again my argument is based on building an API not a Website.
>Doesn't sticking with Django lock you into the ORM and it's capabilities itself?
Not really. You're always free to use raw SQL, and it makes it pretty convenient to do so for the occasions when what you want exceeds the ORM's capabilities (which will likely happen).
>Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point.
I was talking about the django extensions. Stuff like a rate limiter, for instance, or a pluggable social media authentication backend. Or the one mentioned by the OP. All useful when making APIs.
>I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers
You're not railroaded into using any of those things if you don't want to (the same way you are with RoR). All of them are optional and most of them are even swappable without too much effort.
So this argument has now been forked into Django's ORM capabilities and wether or not you should use Django for an API. The former is up to taste, the latter is not.
> Not really. You're always free to use raw SQL, and it makes it pretty convenient to do so for the occasions when what you want exceeds the ORM's capabilities (which will likely happen).
I can't argue with this, fine.
> Stuff like a rate limiter, for instance, or a pluggable social media authentication backend. Or the one mentioned by the OP. All useful when making APIs.
Rate limiter is framework independent, can be built using Redis with a few lines of code. So not applicable.
Pluggable social media authentication backend is for websites not APIs for APIs you most commonly use API key/secret. for an api you can still build your portal in Django and do all authentication/whatever there and simply sign requests for the API.
> You're not railroaded into using any of those things if you don't want to (the same way you are with RoR). All of them are optional and most of them are even swappable without too much effort.
I am familiar with Django, and I know that you can (not the ORM though), but do you want to drive a monster truck when all you need is a car to get around? You could, you will get odd looks though.
Since you can't use Django's ORM anywhere else you need to use something that another "car" supports.
I'll leave you with: "if all you have is a hammer everything looks like a nail"
>So this argument has now been forked into Django's ORM capabilities and wether or not you should use Django for an API.
The two are inextricably linked as far as this thread is concerned.
>Rate limiter is framework independent, can be built using Redis with a few lines of code. So not applicable.
Mine is apparently 200 lines of code (library total) and tied to the framework. I guess you are more of a "reinvent the wheel" type programmer.
>Pluggable social media authentication backend is for websites not APIs
APIs do all manner of different things.
Last time I built an API it was a back end for an iphone app. It needed an authentication backend. By using a pluggable framework I could not only let the app log in/sign up using facebook tokens, I could with one added line add twitter or ~40 other back ends, saving me from... reinventing the wheel.
> for an api you can still build your portal in Django and do all authentication/whatever there and simply sign requests for the API.
Or you could just use django for the API as well the portal since it handles everything about making APIs pretty well (with the exception of high load APIs).
>for APIs you most commonly use API key/secret.
For APIs there are many common ways of doing authentication. There's no standard. Basic auth over https, token, oauth, key/secret, cryptographic signature. If you ascribe to a "one true way" you lack judgement and experience.
>I am familiar with Django, and I know that you can (not the ORM though), but do you want to drive a monster truck when all you need is a car to get around?
I already refuted your point that it was a monolithic heavyweight beast. It's composed of multiple small modules all of which exhibit loose coupling and each of which can be used independently or not at all.
>Since you can't use Django's ORM anywhere else
Utterly false. You can use it wherever you like, independently of everything else (sometimes I do that).
Feel free to argue that you don't like it or it's wrong for whatever situation but please refrain from making shit up to justify your point.
Some advice also: curb your instinct to reinvent the wheel, no matter how simple that wheel may seem.
I'm not arsed to explain to you half of what is wrong with that comment, wtf I know you can use the ORM outside of Django but why the f*ck would you.
You're just arguing like a 10 year old fan boy now. Django is great for sites I love it. I also use other tools when I need different things. As for reinventing the wheel it's a very simple code snippet taken from a reliable source then changed to fit needs. So go home sleep learn new things... Don't attempt to build the next OS in Django.
Flask's import time side-effects and has global objects everywhere. It's great for a quick hackathon and a great eco-system, though arguably you can just use Pyramid for that.
In my experience, growing bigger with Pyramid has been much easier than it has been w/ Flask. We found ourselves writing most of Pyramid using Werkzeug when it would've made sense to start off with Pyramid in the first place.
Pyramid's design for extensibility and design decisions are solid and really make a difference if you're building a real app vs a toy app.
I was wounded in what made VIM flake slow while I was using Flask, I'm guessing it's the amount of modules imported at one go. Thanks for making me aware of Pyramid I will look into it further.
You only return a dictionary from Pyramid views and based on the request, you can choose a renderer like JSON.
Look at this example[1] Steps 3, line 16-19. Basically you can develop a Rest API with template rendering side-by-side and you don't even need a framework for it like DRF!
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/), 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.
Having used both extensively, I vastly prefer DRF.
Tastypie is nice if you want to bang out a rest interface directly to your models quickly.
I prefer DRF for pretty much anything else. Two reasons:
1. There's more tools in the toolbox for simple but arbitrary problems. Need a one-off endpoint that takes a POST and returns json and is throttled? The @api_view decorator and company make it easy: http://www.django-rest-framework.org/api-guide/views#functio...
2. DRF is a lot more easily extensible, and that extensibility is well documented. Tastypie's documentation is pretty good, but DRF's is great. I often found myself digging around in tastypie's source figuring how exactly to punch holes and make it do what I want.
Tastypie is great if the way it works out of the box is exactly how you want your API to work. (And for some people, that's probably true.) If not, it's kind of a pain to hack in customizations.
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.
It's a Kickstarter about a Django framework that a large amount of the community have a (vested) interest in. So of course this group of people are going to upvote it, just like node stuff gets upvoted by node people, Ruby by Ruby people, etc.
I wasn't making a statement about human intervention at all. One minute it was doing well on the front page, the next minute it was gone. I noticed that something disappeared/yanked/punted/hid it.
I guess this sort of protection can be helpful, but I hope that it doesn't keep other high quality but less known content out. DRF is popular enough to overcome this false positive, but I wonder if some other lesser-known (but interesting) stuff would be.
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/