undefined | Better HN

0 pointstrpc7y ago0 comments

>A lot of these are pretty inaccurate, at least for modern Django.

I wish you state exactly which of them are inaccurate and why, I sincerely want to know and understand

>1. I'm pretty sure that's not true...You can do things like `path('myapp/', include(myapp.urls))`

so you suggest I create an "app" for every sub-route? every major and non major web framework except Django has a router where you can mount it to any parent and mount any child to it

>4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)[1]

maybe you're right IFF you start using a custom user model from the very beginning, if you happen to forget that, Django will make your life like a hell and will refuse to even pass startup checkups

>5. All these things are fairly straightforward and libraries like Django-Auth cover a huge set of the normal use cases.

I mean authentication tokens not Django's authentication (e.g. signin, signup)

>6. Django Rest Framework is a best-in-class solution for Rest APIs

so you suggest people throw their codebase and start rewriting for DRF?

>9. See 6.

so you suggest I rewrite my applications to DRF just to have JSON http request decoding?

0 comments

2 comments · 2 top-level

acdha7y ago

> maybe you're right IFF you start using a custom user model from the very beginning, if you happen to forget that, Django will make your life like a hell and will refuse to even pass startup checkups

The startup checks are protecting you from more subtle problems because if you switch to a custom model, you need to do a migration for your stored data. That's a one-time process which can be squashed as soon as you migrate the last server running the old code.

> so you suggest I rewrite my applications to DRF just to have JSON http request decoding?

DRF is a helpful tool which solves a number of common cases but it's not doing anything you can't do in standard Django: that could be as simple as json.loads(request.body) in the appropriate view or, more commonly, a decorator or class-based view which provides standardized error handling, etc.

The reason why the stock forms API doesn't do this by default is that it's designed to support the <form> interface in the HTML standard, which defines a simple key-value interface which is much simpler than what can be expressed in JSON:

https://html.spec.whatwg.org/multipage/form-control-infrastr...

Once you're moving out of the realm of standard browser interfaces it's much harder to write a generic validation interface suitable for having in a standard library, especially since there are multiple competing ideas of what this should look like and most of them are easily installable from PyPI without the Django project having to support them.

rusbus7y ago

Most of your notes are accurate, especially about the difficulty in bringing an old app up to speed. A legacy Django app has very different requirements from someone choosing a framework today.

For 1 it doesn't need to be an app, I just gave that example for clarity. You can include any set of urls (and can create nesting within your app if you desire). Of course, the Django folks would probably suggest that if you have so many urls that it becomes cumbersome, perhaps your app should be broken up.

6. You can DRF for individual routes and regular Django for others.

j / k navigate · click thread line to collapse