Can I ask what you like about Django? As a former Django user I've become quite jaded on the framework, and would caution you against using it if you need data integrity, performance, or a complex front-end.
Data integrity is based on your datastore, not a web framework (or even an orm), performance is relative as generally the performance issue in a web application is the database and not the web framework, a complex framework? Just write the front-end with react and build the backend bits in django. I use django every day happily and fail to see any of these as reasons to dislike it.
Now if you had mentioned heavy concurrency I might actually take your comment a bit more seriously. Then the answer is don't use Django or python, use golang or C/Rust.
No, data integrity is not based on your datastore alone. How the app uses it is paramount. It's very easy to write apps that lose all sorts of data due to concurrent requests trampling each other even if you have a DB with the best consistency guarantees possible.
If you have an sql based system and you aren't relying heavily on optimistic/pessimistic locking for record mutation, there is a good chance your system has all kinds of risks to lose data.
If you are going to "select" something, mutate it in your python code, and then commit it back without exclusively locking the rows you want to edit, then of course you'll run into data races when concurrent requests attempt to mutate the data!
Ditching Django and using SQLAlchemy or even just the lowly dbapi directly will not alter this fact; indeed, it is something everyone who works with a database should know.
I'd like to add that by the time you built your full featured web application on tour favorite microframework with your choice of plugins and custom code, you'll have a partial buggy reimplementation of Django
Any chance you could go a bit deeper on these issues?
I particularly don't understand the "complex front-end" part. What about django's templating system hinders implementing a rich javascript based UI?
I've been quite happy using the templating system to deliver data to the front end and then using whatever js libs / frameworks I've needed to display the data to the user....
Reading the blog post the complaints on no Data Integrity seem to be a symptom of not using models/data store correctly. Problems not specific to Django or any other web framework.
1. Data races - Use a combination of model versioning and uniqueness checks to prevent data races.
2. get_or_create/update_or_create - Duh, the atomicity is enforced by the parameters you use. Create unique indexes on the model for the things you expect to use in your parameters
Django's transaction-related behavior is documented and configurable. ATOMIC_REQUESTS, which the author complains about, causes Django to automatically wrap each request/response cycle in a transaction. This can be good or bad, depending on the workload, the database, the database's configuration and the types of responses you're sending out (streaming responses might not fully render until after the automatic transaction commits!). So it's off by default.
Django also lets you have fine-grained control of when code will or won't execute in a transaction, so relying solely on transaction isolation (when code might not be running in a transaction, either due to global configuration or local override, and which may be a bad idea anyway -- see next paragraph) doesn't get you all the way to safety for get_or_create()/update_or_create(), hence the documentation recommends you either be careful or use query parameters which involve DB-level uniqueness constraints. Also, for the record, you can tell Django to only query for or update a particular set of columns on a model when round-tripping to and from the DB; the default behavior when you don't explicitly specify a set of columns is to retrieve or insert all of them.
The advice to use READ COMMITTED on MySQL is due to MySQL. On SQLite, the only available behavior is equivalent to SERIALIZABLE. On Postgres, REPEATABLE READ guarantees that, once a transaction begins, changes made in other concurrent transactions will not be visible to it. On MySQL... REPEATABLE READ guarantees that, once a transaction begins, changes made in other concurrent transactions will not be visible to SELECT queries. INSERT, UPDATE and DELETE, however, still see those changes and will happily bomb you out with integrity errors because you did a SELECT (in order to determine whether to follow up with INSERT or UPDATE) and another transaction changed the data you were working with. So on MySQL, REPEATABLE READ is discouraged. If your workload can handle it, by all means use SERIALIZABLE instead, but most people can't and so end up with READ COMMITTED, which at least reduces the window of opportunity for another transaction to make surprising changes to data you're working with. Django also provides access to SELECT FOR UPDATE to allow locking rows you're about to mess with.
I've skimmed the rest of the article and it appears to mistake abrasiveness for honesty and hyperbole for insight, with a healthy dose of representing subjective disagreement over design as a matter of objective correctness or incorrectness. But if you've got questions about other claims it makes, I'm willing to answer them.
For data integrity and performance I would not necessarily use an ORM, which I used for this project as it was a small backend, rapidly developed to satisfy a business need. However, I think Django can easily handle complex front-ends, data integrity etc - it simply depends on your design choices and especially your data store.
