Trying not being the devil's advocate here, I have to disagree with some of your considerations. Yes Django + DRF are a great set of tools to help you deliver fast and on deadline.
But, as in any other language/framework some tradeoffs have to be taken into account when your application starts to grow.
As I mentioned Django and DRF are tools. And as such, they have to be chosen carefuly when doing specific tasks. E.g. You mentioned ModelSerializer being evil. It's just a "shortcut" for a specific situation (serialize a model). Even the docs says: "Often you'll want serializer classes that map closely to Django model definitions". If you don't need it to closely map, you shouldn't use it. The same with nested model serializers (you can always fall back to the to_representation).
Some things you mentioned are quite the same for every language/framework. If there's a change on your database, you will have impact on you business logic if the change is not backward compatible (e.g. removing a table field). And that's why we should have tests. Imagine a handwritten query hitting a database with a field that has been removed. That's what will happen in a JDBC PreparedStatement in Java or a non-ORM PHP application.
Don't get me wrong. Django and DRF do have problems. I faced a bunch of them. As I did using Java + Spring Boot and other combinations in other languages.
All that being said, I guess you have a very good point on your conclusion: know your tools and know how you want to build your application, most importantly.
Tech Lead at Cobee working to change how the social benefits empower the employees. I have been working with Python +10 years creating resilient and distributed producs
Thanks for your comment, I think you have missed the goal of the article.
Hoewer I said I wanted to share my frustation using Django, actually the goal is helping other people who choose django to be careful with the features they use, that features might be harmful in the long term.
I didn't say the rest of the frameworks are pefect, not even close. Everyone has their own issues. Hoewer every framework have issues, many of them try to separate the different layers of your applications consistently. When you isolate the main layers (Representation - Business - Database), your database changes don't need to affect your business logic, even you can change the representation of you data without affecting your business or the Database. For example, you can calculate the field you have just removed, and it won't affect your business logic.
Decoupling the main parts of your application will help you a lot. If you decouple them in a good way, you can modify each layer without affecting your whole application, and when you refactor some parts, you will be so greatful for that :).
A highly test coverage is not necessary good, the tests has to be mantained, when I commeted that part in the article, it is was not something good you need the tests, the tests help your project to be reliable, but the architecture should be the first line of trust.
As you said every tool have their own flaws, I only wanted to show the django issues for the people who is doing any project.
I recommend Clean Architecture (from Robert C Martin), if you have not read it yet. The book shows why it is important keeping the differnt application layers isolated.
We agree about knowing the tools is one of the main points, this article try to help other people to understand better these tools.
Thank again for your comment!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Trying not being the devil's advocate here, I have to disagree with some of your considerations. Yes Django + DRF are a great set of tools to help you deliver fast and on deadline.
But, as in any other language/framework some tradeoffs have to be taken into account when your application starts to grow.
As I mentioned Django and DRF are tools. And as such, they have to be chosen carefuly when doing specific tasks. E.g. You mentioned
ModelSerializerbeing evil. It's just a "shortcut" for a specific situation (serialize a model). Even the docs says: "Often you'll want serializer classes that map closely to Django model definitions". If you don't need it to closely map, you shouldn't use it. The same with nested model serializers (you can always fall back to theto_representation).Some things you mentioned are quite the same for every language/framework. If there's a change on your database, you will have impact on you business logic if the change is not backward compatible (e.g. removing a table field). And that's why we should have tests. Imagine a handwritten query hitting a database with a field that has been removed. That's what will happen in a JDBC PreparedStatement in Java or a non-ORM PHP application.
Don't get me wrong. Django and DRF do have problems. I faced a bunch of them. As I did using Java + Spring Boot and other combinations in other languages.
All that being said, I guess you have a very good point on your conclusion: know your tools and know how you want to build your application, most importantly.
Hi Alexandre,
Thanks for your comment, I think you have missed the goal of the article.
Hoewer I said I wanted to share my frustation using Django, actually the goal is helping other people who choose django to be careful with the features they use, that features might be harmful in the long term.
I didn't say the rest of the frameworks are pefect, not even close. Everyone has their own issues. Hoewer every framework have issues, many of them try to separate the different layers of your applications consistently. When you isolate the main layers (Representation - Business - Database), your database changes don't need to affect your business logic, even you can change the representation of you data without affecting your business or the Database. For example, you can calculate the field you have just removed, and it won't affect your business logic.
Decoupling the main parts of your application will help you a lot. If you decouple them in a good way, you can modify each layer without affecting your whole application, and when you refactor some parts, you will be so greatful for that :).
A highly test coverage is not necessary good, the tests has to be mantained, when I commeted that part in the article, it is was not something good you need the tests, the tests help your project to be reliable, but the architecture should be the first line of trust.
As you said every tool have their own flaws, I only wanted to show the django issues for the people who is doing any project.
I recommend Clean Architecture (from Robert C Martin), if you have not read it yet. The book shows why it is important keeping the differnt application layers isolated.
We agree about knowing the tools is one of the main points, this article try to help other people to understand better these tools.
Thank again for your comment!