Hacker News Reader

Comment by mpdehaan2 | Hacker News Reader

Mostly, I prefer to have things already done for me so the micro-frameworks quickly build into added work later.

One of the secret weapons of the Django world is Django REST framework. The built-in API browser alone is pretty amazing.

South is also a pretty darn good migrations system, and is well up there too.

I think I could take or leave the Django admin panel for an established app, but for small apps or just getting started, it's a nice thing to have too.

We don't use Django's templating system.

View on HN

DRF is great, but it's pretty heavy weight. I've used both DRF and Flask for building API's. I was far more productive with DRF at first, but once I developed my own system for flask, I much preferred bare-bones flask coding. It's really nice to have all the code that could be causing bugs, directly in front of you.

> DRF is great, but it's pretty heavy weight.

What does this even mean? It can do a lot for me, therefore it's bad?

We use DRF extensively, but we don't come close to using everything that it can do. We don't tend to use ViewSets or the auto-routing features, but the fact that it can do those things doesn't hurt us.

DRF gets so much attention from such a large community. It's constantly improving to the point where we don't have to worry about it. If you fall victim to NIH Syndrome and roll your own, you have to be proactive about finding and addressing your own issues, as well as keeping up with advancements around the ecosystem.

I'd just rather let the people who focus on DRF handle that, and we'll throw a pull request over the wall if we run into anything that hasn't been addressed.

An example of where this excess bloat would be bad is in a microservice architecture. Django has a footprint so big that using it for microservices doesn't make sense, because at that point you may as well roll all the services into a single application. In that case, I think DRF is great. But if I'm building a microservice architecture, I want the API code for each service to be 100-200 lines, not 100-200 lines + Django.

So yeah, there are efficiency gains from DRF, I agree. But (in my opinion), the gains are far less in architectures with separate applications all using DRF. In that case, something like Flask makes more sense to me, purely for the benefit of debugging, logic clarity, and independence.

I recommend a great talk by Kenneth Reitz on exactly this topic. [1] (He's given a variation on it multiple times -- just search youtube.)

[1] https://m.youtube.com/watch?v=U2frH932U1g

> An example of where this excess bloat would be bad is in a microservice architecture.

Django is pretty easy to slim down. Yank the middleware you don't need, stick to what you do. No need for stuff like context processors if you are using DRF. You don't have to use models or the ORM at all if you don't want.

I think the line count would be very similar for many cases. For example, if your flask app needed DB access, you'd end up pulling in and boilerplating an ORM anyway. Ditto for sessions/authentication/etc.

That sounds dangerously close to "not invented here syndrome."

You can get pretty bare-bones with DRF. I enjoyed working with it because it has magic for when you need it, and low-level functionality for when you need more control.

South is deprecated now - Django 1.7 has migrations built in.

Reply on news.ycombinator.com