Live data from Hacker News

Django REST framework 2.3 released: ViewSets and Routers

django-rest-framework.org

21–30 of 37 posts

Re: Django REST framework 2.3 released: ViewSets and Routers

#21
post #11
post #5

Anyone care to weigh in about using this vs., say, TastyPie?

We looked at and started playing with TastyPie over at Pathwright, but ultimately found that it was very difficult to customize to our needs (mostly with respect to custom API resources, custom filtering, and very fine-grained permissions based on a number of factors). The documentation isn't organized very well, and at the time (a few months ago), it appeared that development had stalled. After getting pretty frustr…

To be fair, tastypie development seems very active right now. Look at the commit history: http://git.io/Na3iHQ

Re: Django REST framework 2.3 released: ViewSets and Routers

#22
post #14
post #5

Anyone care to weigh in about using this vs., say, TastyPie?

The Rest Framework is a lot more flexible and just don't get into your way when you need your API to do anything else than exposing CRUD operations. The whole design of DRF makes a lot more sense for my use cases. TastyPie provides you with Resources that do everything from accepting and dispatching methods, querying db, authentication and authorization to parsing an serializing data. If you want to modify one puzzle…

It feels like DRF is trying to do too much. I'm not a fan of Django's generic views for much the same reason.

I really wanted a framework that was as easy to use as plain Django views while still handling the REST heavy lifting.

So I made Delicious Cake: https://github.com/pretend-money/delicious-cake

It's based on Tastypie, but features a complete Resource re-design that moves serialization and validation out of the Resource. The power of a REST framework w\ the flexibility of plain old Django views.

Two companies are using it in production and a few more are evaluating it. If you love-hate TastyPie you might like it.

Re: Django REST framework 2.3 released: ViewSets and Routers

#24
post #12

Earlier quoted context omitted.

Author here... The boilerplate comment is definitely valid, and is pretty much what this release was intended to address. We've now introduced ViewSets (an extension of class based views that is similar to Rail's controllers) and Routers, which make it super quick and easy to get your API up and running. The updated README should give you a good idea how simple the APIs can be now: https://github.com/tomchristie/djan…

I'll take boilerplate over magic any day. The thing that irked me the most about TastyPie was the magic and lack of obvious understanding of what was happening under the hood (without source diving). The Zen of Python has something to say about this.

I'd be curious to know what magic is in tastypie? It's some of the most straightforward python code I've ever read.

Re: Django REST framework 2.3 released: ViewSets and Routers

#26
post #5

Anyone care to weigh in about using this vs., say, TastyPie?

Django REST framework inherits its Views from Django's Class-Based Views. If your app is using CBVs elsewhere, it is one less interface to have to get familiar with. When I need to do something a little advanced the familiar methods get(), post(), dispatch(), get_queryset(), etc are present. Also, most Mixins for Django's CBVs work fine with Django REST framework's Views. Django REST framework separates its logic int…

> It(Tastypie) has URL routing, which makes setting up an API namespace in your URLs super simple.

Isn't that something that this release has added, and the new release, is, the main theme of this discussion.

Re: Django REST framework 2.3 released: ViewSets and Routers

#27
When I found this for http://www.socialocale.com it was a godsend! It made the weird database operations a breeze when working with third-party libs like Userena. It also gave me a concise, modular way to get/put information.

If your project is complex, I feel like the Django Rest Framework will be by your side the whole way. It's very well thought out and nicely documented.

Re: Django REST framework 2.3 released: ViewSets and Routers

#28
post #5

Anyone care to weigh in about using this vs., say, TastyPie?

I'm actively using both frameworks on separate projects and have roughly 1 year of experience with Tastypie and 2 months of experience with DRF. Both have strengths and weaknesses with very similar feature sets, although I personally prefer DRF, backed up by my choice to use it over Tastypie when starting a new project 2 months ago.

Tastypie has a rather monolithic structure (most of the logic is wrapped in a single resource object) that passes responsibility from function to function. I find the code hard to read and mentally compartmentalize the various components. It does a great job providing basic functionality out of the box, but as soon as you start to do anything complex you will find yourself repeatedly digging through Tastypie source code to track down behavior. Tastypie approach to URLs is also rather limiting.

DRF uses Django class based views and generally follows Django's design patterns. I find the code much easier to understand and more inline with the direction Django is heading. The module class structure makes it much easier to build reusable components. One downside with DRF is their permissions system, it has a rather large oversight for multiple object permissions. DRF completely excludes the queryset from the permission decision which leads to some terrible workarounds (I'm not sure how you can make an informed permission decision on a set of objects without access to the set of objects themselves).

The documentation and community on both is rather strong, although there is more information on Tastypie as they've been around longer. As a point of reference, Tastypie has ~750 questions on stackoverflow vs 153 for django-rest-framework. Both are actively maintained, but Tastypie's design architecture handcuffs it's ability to move forward.

tl;dr; My $0.02 - Tastypie was the standard, DRF is becoming the standard. I would personally choose DRF over Tastypie for any future project.

Re: Django REST framework 2.3 released: ViewSets and Routers

#29
post #5

Anyone care to weigh in about using this vs., say, TastyPie?

I'm actively using both frameworks on separate projects and have roughly 1 year of experience with Tastypie and 2 months of experience with DRF. Both have strengths and weaknesses with very similar feature sets, although I personally prefer DRF, backed up by my choice to use it over Tastypie when starting a new project 2 months ago. Tastypie has a rather monolithic structure (most of the logic is wrapped in a single…

The ability in 2.3 to use multiple filter backends is partly intended to address queryset permissions adequately. It means you can setup a filter backend to deal with any permissions-based filtering, while still including client-determined field filtering/searching etc...

Re: Django REST framework 2.3 released: ViewSets and Routers

#30
post #11

Earlier quoted context omitted.

We looked at and started playing with TastyPie over at Pathwright, but ultimately found that it was very difficult to customize to our needs (mostly with respect to custom API resources, custom filtering, and very fine-grained permissions based on a number of factors). The documentation isn't organized very well, and at the time (a few months ago), it appeared that development had stalled. After getting pretty frustr…

To be fair, tastypie development seems very active right now. Look at the commit history: http://git.io/Na3iHQ

Back when we were evaluating API frameworks earlier in the year, this is where TastyPie was: http://toastdriven.com/blog/2013/feb/05/committers-needed-ta...

It's still not clear how the project will do without its original maintainer going forward. I don't bring this up as damning evidence against TastyPie, but it is something to consider. Some projects achieve that critical mass where life continues after the original maintainer steps out, but enough time hasn't elapsed to see how it will play out in this case.

Post reply on HN