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 want to. Doing raw sql queries is perfectly possible. Rendering with jinja instead of django's template system is possible. Speaking to redis directly: possible. Returning a string instead of something rendered: possible.
Heck, even speaking to the django db from another project with sqlalchemy worked out quite alright.
A big problem in large projects is too many queries per view, or unoptimized queries. Django's orm often gets the blame. But I did see that happen with ORMs in other frameworks as well (flask, bottle although an orm is optional). Even raw sql. Another nice feature of django 2.1 will be the .explain() method on querysets. Im using 2.1 to debug queries now and switch back to 2.0 when things are speedy again.
Another problem is having way too many unused variables and unclear calls to database from templates. But that is also a big problem in flask etc.
I think it is a myth Django is a hell for big projects, there are plenty big companies and websites which prove im right. Of course there are struggles. But those struggles are there with other python frameworks as well.
A lot of work happens quickly beyond the framework you use anyways. When a website grows many background jobs have to run or many business rules have to be programmed at some place. This does not have to do with the framework and often times just happens to become messy. I think of the work i do in django projects 30% is django related 70% is django unrelated.
You can consider to use another _static_ language and framework for speedups, like play or something. But i think the parent poster meant Django is a hell compared to other python frameworks.
I do wish django could do some async stuff, like the play framework does. It would be just nice to fire off a few db queries and resize an image and just wait for the result at the moment you build the response. But other than that it is superb!
I've worked on plenty of large projects and haven't run into places were I've "lost control". Just the opposite, I have found it to be very extensible.
I'm curious if there are cases I haven't hit that you have, though.
Django is perfectly fine for large projects. It's not the size of your project that will end up being a problem it's what you're trying to build that can be an issue.
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.
I think that generally applies to most frameworks, but I've noticed it heavily with django. Developers get upset that Django isn't working for them when they are actively avoiding best practices and going out of their way to fight it.
If you are fighting a robust framework, you are probably doing something wrong and should take a step back.
Actual control... where? And why is it too late? Too late for what?
You can get actual control everywhere if you want to. Doing raw sql queries is perfectly possible. Rendering with jinja instead of django's template system is possible. Speaking to redis directly: possible. Returning a string instead of something rendered: possible.
Heck, even speaking to the django db from another project with sqlalchemy worked out quite alright.
A big problem in large projects is too many queries per view, or unoptimized queries. Django's orm often gets the blame. But I did see that happen with ORMs in other frameworks as well (flask, bottle although an orm is optional). Even raw sql. Another nice feature of django 2.1 will be the .explain() method on querysets. Im using 2.1 to debug queries now and switch back to 2.0 when things are speedy again.
Another problem is having way too many unused variables and unclear calls to database from templates. But that is also a big problem in flask etc.
I think it is a myth Django is a hell for big projects, there are plenty big companies and websites which prove im right. Of course there are struggles. But those struggles are there with other python frameworks as well.
A lot of work happens quickly beyond the framework you use anyways. When a website grows many background jobs have to run or many business rules have to be programmed at some place. This does not have to do with the framework and often times just happens to become messy. I think of the work i do in django projects 30% is django related 70% is django unrelated.
You can consider to use another _static_ language and framework for speedups, like play or something. But i think the parent poster meant Django is a hell compared to other python frameworks.
I do wish django could do some async stuff, like the play framework does. It would be just nice to fire off a few db queries and resize an image and just wait for the result at the moment you build the response. But other than that it is superb!