7 ms·

Why Django is not good, here are some of my reasons as far as I can remember: 1. mediocre routing (no nesting, all routes have to be declared in one place) 2.

• pleasecalllater 8y ago
  > 1. mediocre routing (no nesting, all routes have to be declared in one place) In reality these can be multiple places, however not really nested. There is the main routing file, which can move resolving a url to another file. > 2. mediocre middleware (middleware is global) Isn't it how it should work? The middleware is something your want always run for the request. > 3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like a decade Not really. On the other hand I always prefer SQL... but using SQL in the Django ORM and pushing the results into Django model classes is simple. > 4. custom user model? good luck fighting with Django errors to make that happen Done that a couple of times... https://docs.djangoproject.com/en/2.1/topics/auth/customizing/ https://docs.djangoproject.com/en/2.1/topics/auth/customizin... > 5. custom authentication? external authentication? good luck No luck needed: https://docs.djangoproject.com/en/2.1/topics/auth/customizing/ https://docs.djangoproject.com/en/2.1/topics/auth/customizin... > 6. Django is built for 2000s websites not REST/gRPC era True, that's why we have e.g. this https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ > 7. want to use graph databases? noSQL? good luck Yup. I'm using SQL and I'm with it. Graph databases are cool for some specific problems, you can also use the core Django models and store some more stuff in the graph database. As for all the noSQL mess, well, it's usually a mess with thousands if programs running just to clean the data, and almost nobody cares about the correctness of the data model, thank you, I'd rather stay with the good old SQL. > 8. external migration for SQL? oh god, prepare yourself for the mental hell I'm not sure I can see a problem here... but I'm half-dba, half-programmer, half-dragon... so maybe that's why. > 9. Django as far as I can tell still ONLY supports decoding "x-www-form-urlencoded" bodies, yeah no JSON, it's that pathetic I'm sure I was using json with django without any problems in both directions. But you know, I'm different. Yep, Python has lots of problems, and I'm not sure I like it (especially after moving to Kotlin for 97.49% of the code). However, if you stay with Python, I'd recommend Django :)
• rusbus 8y ago
  A lot of these are pretty inaccurate, at least for modern Django. 1. I'm pretty sure that's not true if I'm correctly interpreting what you mean...You can do things like `path('myapp/', include(myapp.urls))` 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] 5. All these things are fairly straightforward and libraries like Django-Auth/Django-Rest-Auth cover a huge set of the normal use cases (OAuth, JWT, tokens, etc.) 6. Django Rest Framework is a best-in-class solution for Rest APIs 9. See 6. [1] https://wsvincent.com/django-custom-user-model-tutorial/ https://wsvincent.com/django-custom-user-model-tutorial/
  • mazelife 8y ago
    Also #7, "want to use graph databases? noSQL? good luck" Is incorrect. How do I know? I've built a non-trivial Django app with a Neo4J backend. It included an API using Django REST framework. There are some parts of Django that are tied to the ORM, mainly the admin and some generic views. But you can certainly use Django without those pieces.
  • trpc 8y ago
    >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?
• ibejoeb 8y ago
  Barely anything worth responding to here, but come on... Django is probably the easiest ORM to use. It's powerful and extendible, and it is in line with Django's "batteries included" philosophy, so, for example, it requires a single-attribute primary key. That doesn't mean that you can't do composite keys; it's just that you need a surrogate. It also has very good API for custom functions and aggregates, meaning you can quickly add support for vendor-specific features, and also offers very good raw SQL support, where it will handle handle the mapping on your behalf, which is the most tiresome of boilerplate.
• kriberg 8y ago
  1. You can nest routes, see [1]. 3. You can do arbitrary SQLs through the ORM. You can also do arbitrary SQLs with whatever joins you like and still get a model back. See [2]. 4. This hasn't been an issue for some time. See [3] for how to extend and [4] how to substitute with your custom model. 5. There are libraries supporting relevant oauth providers [5] and libraries for specific protocols like ldap [6]. These are drop-in libraries that needs only basic configuration. It's also quite simple to build a custom authentication system, using whichever http header you fancy. 6. While this is somewhat true, it's not fair. There are libraries for many purposes. django-rest-framework [7] is an exceptionally good framework for creating ReST APIs. 7. There's nothing stopping you from using any other database, neither graph nor nosql. 8. Django's migration support is extremely good. If you dislike the ORM and you also want to use an external migration tool, you can easily enough just omit using models and utilize sqlalchemy instead. [1] https://docs.djangoproject.com/en/2.2/topics/http/urls/#including-other-urlconfs https://docs.djangoproject.com/en/2.2/topics/http/urls/#incl... [2] https://docs.djangoproject.com/en/2.2/topics/db/sql/ https://docs.djangoproject.com/en/2.2/topics/db/sql/ [3] https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#extending-the-existing-user-model https://docs.djangoproject.com/en/2.2/topics/auth/customizin... [4] https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/2.2/topics/auth/customizin... [5] https://python-social-auth-docs.readthedocs.io/en/latest/configuration/django.html#authentication-backends https://python-social-auth-docs.readthedocs.io/en/latest/con... [6] https://django-auth-ldap.readthedocs.io/en/latest/ https://django-auth-ldap.readthedocs.io/en/latest/ [7] https://www.django-rest-framework.org/ https://www.django-rest-framework.org/