31–40 of 225 posts
If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.
DRF is nice enough 90% of the way, but when you need to do something that its authors haven't really thought of, you need to dig in very deep to fix things, I've found. :/
Django’s documentation is still the best I have worked with so far of any software project I came across to date. It not only explains, it educates.
I find it some of the hardest documentation (close to AWS) to understand the best way to do something. I think it's great if you know what you're doing or you have a rough idea of what to do but need more information, but for someone new to the framework it makes me want to paper cut the webs of my fingers and bath my hands in vinegar because it would be less painful.
Earlier quoted context omitted.
Isn't Flask simpler for REST stuff?
Sort of, but you'll have to assemble several different libraries to make it good. It doesn't handle request validation, JSON serialization/deserialization, or databases well out of the box. If you use Flask with Flask-SQLAlchemy be sure to use apply_driver_hacks to enable the pool_pre_ping option or you'll end up in production wondering why 1/3 of your requests are getting a bad DB connection from the pool. Honestly,…
[0] http://hug.rest
Django’s documentation is excellent, but parts of the wiki are out of date. This page has barely been updated in the last four years. It mentions MIDDLEWARE_CLASSES (deprecated in Django 1.10) and using strings in url() (deprecated in Django 1.8). There may well be other bits which are out of date. The entries in the faq [1] are more likely to be kept up to date. [1]: https://docs.djangoproject.com/en/2.0/faq/
The official documentation (at docs.djangoproject.com) is scrupulously maintained, and excellently written.
Earlier quoted context omitted.
Isn't Flask simpler for REST stuff?
Sort of, but you'll have to assemble several different libraries to make it good. It doesn't handle request validation, JSON serialization/deserialization, or databases well out of the box. If you use Flask with Flask-SQLAlchemy be sure to use apply_driver_hacks to enable the pool_pre_ping option or you'll end up in production wondering why 1/3 of your requests are getting a bad DB connection from the pool. Honestly,…
I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free".
I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. There is stuff you don't realize you need until some enterprise customer requires it for your product to even be considered. Auditing, session retries/timeouts, etc. With flask you can just add another library but it isn't as connected as Django is. And that matters a lot when you get bigger because it affects discussions about what the right way to do things is. You generally have discussions about what is the right Django way vs what is the right way in general.
Earlier quoted context omitted.
DRF is nice enough 90% of the way, but when you need to do something that its authors haven't really thought of, you need to dig in very deep to fix things, I've found. :/
I think this is true of django in general.
Probably goes for all opinionated frameworks. That's part of the tradeoff you make when choosing one.
Django is a hell for APIs and big projects. It's good for beginners and small projects, but once you need the least amount of actual control, you will find it's too late
I read this a lot, but I do not agree. Worked on quite large (and busy) websites, did not experienced problems with exactly that. And if the project really is that large, perhaps it is time to split things up? (I intentionally avoid the term microservices, because there are more ways to split things up.) Actual control... where? And why is it too late? Too late for what? You can get actual control everywhere if you w…
Earlier quoted context omitted.
Agreed, but with the caveat that there are a lot of bad parts of DRF. It's probably the best tool to build a REST API, but only if you're using some minimal subset of the tools available.
What are the bad bits? Why are they bad?
Django is a hell for APIs and big projects. It's good for beginners and small projects, but once you need the least amount of actual control, you will find it's too late
Most application built today, as in in-house development projects, are basic CRUD applications. Perhaps with some integrations to other systems and maybe a little calculation thrown in. I doubt that many, regardless of size will run into any really challenges.
In terms of API, yeah, Django Rest Framework may not fit you're use case, and if that's the case there's little point to building on Django at all. For the most part, what I've seen, if DRF doesn't work for you, check that you're not actively fighting the framework. Doing the API as DRF want's you to may not result in the API you want, but it will give you a pretty nice REST API in the end.