4 ms·

> 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

by gtaylor 12y ago

> 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.

chatmasta 12y ago
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 https://m.youtube.com/watch?v=U2frH932U1g
- gtaylor 12y ago
  > 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.

by gtaylor 12y ago

chatmasta 12y ago

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 https://m.youtube.com/watch?v=U2frH932U1g

gtaylor 12y ago
> 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.