4 ms·

It's great that you've written a thoughtful critique about such nuanced and valid points, but from reading your post, it's not totally clear to me what you thin

It's great that you've written a thoughtful critique about such nuanced and valid points, but from reading your post, it's not totally clear to me what you think are viable solutions to making (1) requests more atomic and (2) validation more intuitive. Regarding (3) testing complex dynamic templates, I don't have much input as I tend to build APIs using Django Rest Framework rather than web apps with Django templates. Perhaps serializers and validators in DRF solve some of your concerns. (I'd also be curious to hear what frameworks or libraries you've opted to use instead of Django for your use cases.)

alexbecker 10y ago
I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transaction and perform a second get if it creates a new object, then rollback the transaction if more than one object is returned and use the other object instead (similarly rewrite update_or_create). I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms. I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it. For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.

alexbecker 10y ago

I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transaction and perform a second get if it creates a new object, then rollback the transaction if more than one object is returned and use the other object instead (similarly rewrite update_or_create). I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms. I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it. For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.