Django REST framework 3
kickstarter.com
kickstarter.com
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:
Really dead-simple to use and just plain fun.
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.
http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
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...
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...
Edit: The overhead thing was a secondary point my main point was handling data.
> 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.
It also provides an easy to use means of doing complex queries via raw SQL:
MyModel.objects.extra(select = {'blah blah raw sql'}) will return a regular queryset.
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.
Not familiar with Conduit though so can't compare.
I've used piston, tastypie, and DRF. It is the best of all 3 hands down.
I can't guarantee it, but you make like the approach.
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.
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.
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.
Consider yourself corrected.
>read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old).
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.
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.
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.
> 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"
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.
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.
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.
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.
Anyone working with EmberJS would find this desirable because that is the default format of API it expects.
I think is the closest in python to the (IMHO) best API-framework thing that I have used (http://www.remobjects.com).
I've had a look on their site and can see a number of different products; which is the API framework as it's not obvious to me?
- 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.
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.
Edit: we turned the penalty off.
The only reason I don't do that any more is that someone told me about the voting ring detector.
This is a hard problem and there are tradeoffs.
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.
I share your hope. High-quality, less-known content is exactly what we want more of.