If you're not already using it, check out `django-extensions`. You can use `./manage.py shell_plus --notebook` to launch a Django-friendly Jupyter notebook.
From there you can prototype with extreme ease and confidence.
I have also built a trivial custom model Manager so I can do stuff like:
User.objects.all().to_dataframe("first_name", "last_name", "email")
What am I missing with data-frames?
I've written products that utilized them before (years ago), but it's been long enough that I don't know what I would even use them for in daily programming.
Pandas adds utility methods like join, groupby, and fromsql. Also hierarchical indexing, and a bunch of other stuff that I don't know much about - I'm not in data-science either, but I work with some of them.
Overall, lots of useful stuff for processing tables locally once you've fetched them from SQL or similar. Also, the simple fact of having a tabular data structure without needing to define a custom Row class. Lists of dicts or tuples have a lot of overhead by comparison.
This dovetails nicely with most data science-ie tasks, like statistical analysis, engineering features, simple machine learning techniques (the tables can be easily transformed into numpy arrays), and plotting results.
You can use them any time you feel the need to do table manipulations on non-insanely-large data: aggregate, transform, combine, split, reshape, join...
this approach avoids the full data copy calling '.all()' materializes.
In Python, the repl is an accessory that helps testing small portions of code. In Clojure, the repl augments the editor, becoming an integral part of the development process.
My understanding of the parent argument was that the combo Django/Jupyter/pandas is "an ecosystem that's hard to beat" because of the tight feedback loop between writing the code and seeing what it does.
Furthermore, the marriage of application framework / application model wrappers with industry-leading data science tools sounds particularly special, and orthogonal to the presence of a repl.
I’ve actually had a nightmare where everyone’s auto reloader was broken. While it never runs in production (right?!) it’s actually a pretty critical bit of Django that had not been touched in about 10 years!
At this point, for me Django is pretty much synonymous with Django REST framework (https://www.django-rest-framework.org/). I can't imagine a better API than Django w/ REST framework.
For static sites I use Django's templates. Otherwise, I just use Django w/ REST framework for my API, and to serve up index.html. My index.html will include a link to my JS bundle(s) - I use a separate build system (Webpack/Babel/etc) to handle JS.
Then, you don’t need to serve any static content from your API server and can do away with nginx.
Use the whitenoise package for serving the Django admin pages if you still need them for administrative tasks.
--route '^/static/.* addheader:Cache-Control: public, max-age=7776000'
Disclaimer: The above is not my project
That said, I like Django. Of course, I liked Rails better, but maybe that's because it was my 'first' and I never used any of the big php frameworks for a long period of time.
I quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller things, but you just end up re-implenting django. I'd rather someone made those decision for me.
This is an area that I think is poorly documented (both in the otherwise-great official docs and in the broader community). My advice for beginners is to just create an app called `core` and put everything there, until you have a reason to do something else. (I'd also propose putting your DJANGO_SETTINGS_MODULE aka "project name" as "django_settings" and only put your Django settings in there, but that's a little more esoteric and I'd not recommend that to a newbie in order to minimize confusion.)
In general, I think you should take the "monolith first" strategy (e.g. https://martinfowler.com/bliki/MonolithFirst.html) and just use a single app, unless you're writing something that is obviously going to be reused elsewhere.
The alternative is to attempt to define service boundaries before you know what your app's structure looks like; you'll inevitably get it wrong. And migrating models between apps is incredibly painful if you have foreign keys spanning apps.
I've also found a couple bugs in Django's migration machinery that only affect multi-app foreign key relationships; I've never seen a single-app migration bug. So there's a real cost to going down the multi-app path, which you need to balance against any benefits (I've seen none).
(Credentials/disclaimer; startup using DRF in prod for 3.5 years, mature domain model with ~50 model classes, feeling the pain of incorrectly choosing 5 apps in the initial setup instead of just using one. I'm sure there's a good argument for apps when you get to a larger scale and are sharing components/functionality between teams.)
This is spot on .... Flask is great, but it seems that to get anything substantial done with Flask you must first reimplement big chunks of Djangoesque functionality in it - why not just jump straight to Django?
in top_level_app you then could do
from second_level_app.models import model1
or from a different top level app:
from other_top_level_app.second_level_app.mixins import a_mixin
Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps.
The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then a nested app within that called "blog_editor". This way we can separate blog models, business logic and user-facing behaviour, from CRUD interfaces designed for internal users. In the latter, if we have 3 shipping providers, we might have an app "shipping" with the core shipping models, with nested apps for "ups", "royal_mail", "dpd", etc, each of which might have the necessary models needed to manage uploading to their APIs, business logic, etc. There may be a common-ish interface exposed by these apps.
This structure is probably the thing I like most about Django over, say, Rails. It's not necessary for all Django projects, but I think it's pretty nice.
I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models.
This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.
Even if the latest version is for 1.11, the concepts are relevant.
I have been looking at a rails like framework in python called Masonite. Does anyone in the python/Django community think this will gain traction?
If you've identified some clean, generic problem where you want to reuse the code or open source it, make it a separate app. If you have a web site with areas that barely interact with each other, make it into separate apps (a chef's website where the recipes are separate from the cooking classes calendar). If you know what you're doing and feel like separate apps will help with organization, then split them up as well. Otherwise, one is fine.
For the most part there isn't any need to, with the exception of things explicitly meant to be shared. So if you are a large company and want a bunch of custom auth logic or something to be shared among many different teams running their own Django service, then you might want to build that as an app. Or else if you were building something as an open source project you might want to do the same.
In terms of separating apps by functionality, I think the main reason many people do it is because they are under the mistaken impression that putting things into different apps will make them magically re-usable. That's not to say you shouldn't do it, only that I think most people do it for the wrong reasons.
In general I would say don't bother splitting up your project into different apps by functionality until you have too many models to comfortably fit into one file. That might not be until 20KLOC. For apps that are less than 10KLOC, I think in most cases the overhead probably outweighs the benefits.
There isn't really any hard rule one how to do this, but you might do something like:
- Account management app for creating and deleting users, getting user profiles, password resets, etc.
- Apps for integrations with third-party APIs, e.g. Duns or Mailgun.
- Apps for different front doors, e.g. if you make a Facebook chat bot that's powered by the same tech that powers your normal website.
And then after that you can possibly split up your business logic of your core website into different logical components, but I would do that last. By the time you get there you should start to have a feel for how to do this.
The one place I use it for our own startup is that we recently built a couple different front doors for our site, and each one accepts data in a slightly different format and has different authentication requirements. I put each of these in their own apps, but everything else is just in one main app.
Even for larger apps in my django project, I convert my models into a package and split all my models into individual files (same with views and serializers for DRF). This keeps my models easier to manage.
- I split the core app up into different views and services based on the functionality. For FWD:Everyone this is basically: account_management, admin_apis, content_discovery, organizations, upload_thread, read_thread, comments, and user.
I have a folder for all my views and a folder for all my services, and for each view there is one (or occasionally two) service files.
So e.g. in the views folder there is a file called account_management_views, and then in the services folder there is a file called account_management_service.
For utilities that get re-used across the entire app I have two additional things in the services folder, one is called util.py and the other is io_util.py.
Util is for things like sanitizing XSS that don't require any database access, and io_util is for things like get_user_from_username, get_user_from_email_address, etc.
Then you can import any models into io_util.py, but never into util.py. And you can import anything from util.py into io_util.py, but never the other way around. Then you can import anything from either util or io_util into any service method and shouldn't have any issues. (Although I always just import util or io_util, and then call the methods like util.sanitize_xss.)
Once I structured the services and utilities that way I never had issues again with circular imports or figuring out where to put stuff. Importing with Python is kind of difficult and janky in general, but so far this pattern seems to be working pretty well for both our startup and also for the consulting projects I've done.
Basically for logic that's mostly specific to a single view, put it in the services file for that view. Public functions in that folder can still be re-used in other services, but if they're fairly generic and they're re-used in more than one or two places then consider moving them into util or io_util so as to avoid circular import issues.
- You may have stuff that may be re-used for multiple projects. For example the departments of your organization and their attributes; these should be extracted to apps so they can be easily used for other projects. Of course this would make sense if you are a software house or an organization that need multiple apps (i.e a bank) not if you are working for a single application.
- Django recommends using a custom user model. I put that in a separate app along with any related classes like user preferences etc. See also my previous bullet.
- Non related models. If you add a model that doesn't have any relation to the rest of your models then maybe you should move it to a different app? For example in one of my applications I have a NewsItem model that is just a bunch of notes that the admins can add and will be visible to the homepage; there's no need to put it in with the rest of the app (of course this also obeys the 1st bullet)
- Beyond that, usually you'll understand when you have to separate your apps. You don't need to force it, I know of huge apps with a models or views py with thousands of lines (of course in such cases even if you think that these should belong to the same app nothing's stopping you from making them a package instead of a module). However you'll usually come to a point where you think that for your reasons you need to separate
* project/models/ (each model gets it's own file here)
* project/views/ (same for views)
...and so on. And in `INSTALLED_APPS` I just add 'project'.
Makes it so I don't waste a bunch of time trying to figure out which app to put a model in, etc.
It doesn’t really swim against the current as long as you import models into the __init__.py file in their package.
The way I think about design is usually centered around the data model, so if some subject has a number of ORM models and is pretty self contained it makes sense to put them in their own app, together with related urls and views and stuff.
They still live in the same repository and aren't meant to be re-used, just split into logical parts to make the code base easier to think about. Modules, in other words.
If you don’t want “magic” then your solution is right - just use Flask.
A small nitpick: While Django may indeed fill that role, it's actually older than Rails, so wasn't "supposed" to do that. Both projects have been created independently of each other.
$ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 --
percent --markdown django pyversion
Served from cache: False
Data processed: 160.22 GiB
Data billed: 160.22 GiB
Estimated cost: $0.79
| python_version | percent | download_count |
| -------------- | ------: | -------------: |
| 3.6 | 39.61% | 3,277,927 |
| 2.7 | 29.59% | 2,448,652 |
| 3.7 | 17.53% | 1,450,949 |
| 3.5 | 10.37% | 858,325 |
| 3.4 | 2.76% | 228,150 |
| 3.8 | 0.07% | 5,428 |
| 2.6 | 0.04% | 3,686 |
| 3.3 | 0.03% | 2,103 |
| 3.2 | 0.00% | 220 |
| None | 0.00% | 56 |
| Total | | 8,275,496 |
It shows that 30% of projects being re-deployed are still on Python 2.7.
Upgrading to Python 3 is a chore. We have to do it, but it's not fun and it's barely useful.
can you achieve security with a dead language? I don't think so.
I assume they will simply run on the last 2.7 release until projects are shut down.
e.g. some script has '$python my_program --arg foo' hardcoded instead of '$python3 my_prgram --arg foo'
Edit: Oh, but that doesn't account for the older Python version. Yeah, that is interesting.
I'm sure the IPv6 group expected the world to have migrated more quickly, too.
The lack of (enough) incentive for upgrading used to be a good excuse but with 3.8 we are getting a few performance updates that are hard to ignore. Also, many projects in data sciences are dropping support for legacy Python so sooner or later data processing pipelines will have to catch up.
Yes, upgrading is unpleasant, but it is becoming a matter of hygiene.
Also a fan of these:
https://wsvincent.com/ (and his books are excellent)
Even though a lot of people don't like Django's ORM, at least it does almost everything you would want to do with Postgres. (And if you want more you can always use SqlAlchemy.) Most of the other ecosystems don't even have anything near the baseline functionality built into Django.
- cleaner internal APIs, models, methods
- a lot more stuff that "just works" out of the box where you would need a third-party package in Django (e.g. RoR gives you different settings for development/staging/production out of the box)
- better static file handling
- third-party packages tend to be a bit more mature and stable in the RoR world
However, using Django gives you easy access to the rest of the Python ecosystem, including all the data science and ML tooling. And that trade is worth it. So if you are starting from scratch today, i'd go with Django.
As an aside, I love seeing how different frameworks implement the same features.
Don't you just let nginx/CDN handle these?
You develop by just assuming all your static files would be served by Django itself (and they will - using the dev server) and then change the project’s configuration to use a CDN or S3 (using a library - which will automatically collect & upload your files too) with no change to the underlying code.
I think Django, Laravel, and Rails are really the only 3 frameworks with the levels of ecosystem and built in functionality that these 3 have (unless there's something in Java-land that I'm not aware of). ASP.NET Core is close, but the ecosystem around it is weaker.
Laravel was my 2nd choice, the recent adoption of a JIT into the core really adds some desirability to the space. Not to mention HHVM and how much Wordpress is out there.
I've been giving C#/Asp.Net Core ago since it's been open sourced. I'm loving C# the langauge, but I wish the ecosystem was as rich as the PHP/JS ecosystems.
- The best-governed language in all of software, and the best-governed web framework
- A huge ecosystem of libraries for everything from data science to email processing, that are (mostly) easy to read and modify and free from systemic security issues. And pretty much every major company with an API has an official Python library for that API.
- The standard language taught at most of the top CS programs around the world
- A web framework that's had almost no major security issues over the 10+ years its been around
What exactly would you get in terms of benefits from switching to Ruby? I'm not saying Ruby or Rails are bad tools, I just don't get why someone who already knew Python and Django would switch.
I get that if you run a dev shop it might be a better choice for just cranking out web apps as fast as possible for clients, but if you run an actual startup I don't see that the benefits of saving a couple lines of code would offset the costs of being locked into the ruby ecosystem.
I disagree about this, there's not even a basic user signup flow plugin with page templates that would allow SSO and U2F, it was so when I was looking at it three months ago. With Flask I can use Flask-Security, Flask-Dance and I have user signup, pw resets, SSO. With CSRF protection out-of-box and bunch of other security features are easy to turn on compared to Django. What I did like about Django was the idea and maybe I would've liked Django-Admin if I didn't have to reinvent three wheels out of four.
I don't know a ton about SSO, although I'm more skeptical about building it into Django only because there are many different ways you might want the business logic to work, so to me that suggests using a library for that might be more appropriate than having it built into the framework.
Sorry that these are fairly abstract statements without examples. I need to start tracking them.
For the record I didn't want to do Rails work when I started, and begrudgingly accepted being called a Rails developer only after two years of experience.
You'd get Ruby on Rails.
I don't need to learn a new language I won't use for anything else, I don't need to learn a framework that is not as simple as its proponents describe. I also don't need to learn a new package manager or go digging for gems that do what I need.
If you aren't already invested in ruby, there is very little to gain as a web app developer. It would be a huge waste of time to drop django or flask and learn not only a new framework but also a language that is often described as cumbersome to use.
Ruby on rails might make sense if you already know it, but it makes little sense for anyone else to learn it these days.
C# / .NET core seems to be a strong up-and-comer alternative for teams looking for a full-featured and well-supported application framework with more type safety and performance than Python/Django or RoR. Elixir / Phoenix, as well, but that caters to an entirely different crowd.
I expect most Go users are not using much in the way of frameworks.
Everyone talks about the admin. Yes it is nice, but the real core for me is a sensible way to map URLS to queries. I have taken the filtering and sorting of the admin, and extended it to output dataframes. From there I can take the same admin url, change one part and instead get a csv to download, or a matplotlib plot.
The Django ORM is cumbersome to use for complex queries, especially aggregations. I get around this by writing views that I want to express the aggregations that I want, then putting a model on top of the view. From there I can get easy access to the aggregations through a simple foreign key.
When using Django, I often think "there's a lot of convention around doing this simple thing" or "why did they engineer something this odd way". Then I use Flask and I have to poorly reinvent something that Django has already thought of.
One new feature I’m excited about is bulk_update:
(click "latest games" to see how it works)
Im a big fan of django, and have used it for several projects. Using rest-framework allows you also to make powerful apis, and SPA front ends like Vue or React. It's ORM is also a very user friendly (though aggregations are definitely a pain).
I consistently come back due to the great docs, and the ease of use. Being python based means you can integrate a lot of libraries, especially if you are doing any kind of data science related stuff. Websockets and real time stuff can be cumbersome from my experience, and for that I would stick to node. It's possible to use django-channels but I had a very mixed experience trying this.
I see the esports gaming area exploding over the next 10 years as most people are gaming now instead of other activities.
I use django-background-tasks to run an ETL job every 20 mins that does the matching.
It is growing just among beta customers. Hope to do a release in next month or so. Will post a Show HN.
I also have a client I develop for on a private web app in Django that does a lot of cool stuff w on the fly cloud compute instantiation.
I really like Django and have been hanging out in the #django on freenode.
It may seem boring but it is the most productive setup I've ever experienced; I don't think that there's anything more powerful for such things (except maybe some IDEs like PowerBuilder however I think that these are way too niche on their capabilities; they may be fast and easy to create the thing that they know how to create but god help you if you need to create something more complicated; Django on the other hand is a general purpose framework; whatever you throw at it it will happily eat)
Most of my projects starts with Django. Quick to build quick to test the idea. And because they never grow to 10k concurrent users no need for more scalable solution.
It's an amazing little piece of software, I am gobsmacked by how complete it is.
One thing I'm curious about, coming from well-typed JS codebases using Flow, is the quality of typings in major projects like Django, Pandas, etc. Are their APIs well-typed? Can I get quality types for my models?
Beyond that, the Django core isn't type-annotated yet likely because of Python version support, but I'm sure you can get typeshed pyis or something.
If you mean the object itself, then Python is strongly typed and will throw an error if you try to run the wrong method or access the wrong property on an object (although it will let you assign new ones, and it will let you add new columns to DataFrames of any data type, because that's very useful).
If you mean in the method or function calls, then often a parameter will allow different types because you might want to pass in the column name, a list of columns, a function or something else that makes sense for that particular parameter depending on what the method/function does. Pandas has a lot of overloaded parameters because it's a big library that covers a lot of use cases for tabular data.
With Flow in JS, how would a JSON library for similar purposes work where you don't know what kind of data it will be and you will be doing a lot of transformations on it?
One way Mypy could help do this is by implementing a feature like Type Providers https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...
Scala is a language that is often used for data processing, and is statically typed.
Depending on the situation, codegen can also be useful in these situations, eg; https://github.com/typeorm/typeorm
EDIT: in any case, this certainly answers my question :-) sounds like they're not there yet, and perhaps not even moving in that direction yet.
As any new project, go with you're most comfortable with, so you can prototype and changes things faster. After you reach a good size and understanding of the problem you may refactor stuff for a different language/framework with better reasons for it.
That being said, if you want to use Python but not a "batteries included" framework like Django, so you have better control of the stack, check out Pyramid, it is really good and scales (I'm talking on code maintainability, but also performance-wise) very well from pet-project phase to complex applications.
As a proof-of-concept, I put together a Django plugin that uses Django's validators along with Transcrypt to share validation logic between the server and a `ModelForm`.
I thought it was a neat way to centralize validation logic.
More sophisticated user interfaces I would definitely build in React of course.
Is Django still a thriving development community? And is it able to handle a large amount of concurrent users? Basically is it a good choice for a backend for a new project? The web tech world moves really fast, and I like that Django has been around for years but wondering if it's still a good option.
however, since I've ended up utilizing SQLalchemy and Pandas in a lot of my projects I have since tended to use Flask+SQLalchemy a lot more so my old fuzzy brain doesn't have to try and remember the variations between two different ORM syntaxes.
But at the end of the day, the choice is yours to make and it's simply your loss.
That may be, but it doesn't really matter to me if they put their political views into their code. It can literally be the best framework out there, built by the sharpest minds in the world and I would still use another framework even if it would hurt me economically.
I also think there would be more people like me if that were the case. But just because it's a popular opinion everyone lashes on my 'irrational' behavior. I don't think it's that irrational though.
Yes to some extent. Most secular and democratic societies has agreed to a standard that I defend. Call it status quo if you want. I think decisions like Djangos goes against that standard and is probably why I feel so strongly about this. They want to police speech and force everyone to use specific words.
I don't think we should police speech but there is a lot of people that are pushing for censorship and making some speech illegal today and I simply defend the usage of the words master and slave. I don't think there is anything political about it and they are not racially charged since masters and slaves has occurred in basically all societies through time. Banning the words because of american politics is absurd. I hate the modern american politics, I am not an american and I do not want it in my life.
By doing this, Django forces everyone to think about this and you have to be extremely sensitive if this is what you go around and think/worry about. What else will they do in the future? Ban people from using Django for certain stuff etc? Surely it would be forked etc, but forks rarely works out great in the long run.
Cool. But that’s your politics, and not necessarily everybody’s, and to have a different political position from you is not inherently morally wrong. We could argue about whether or not the status quo is fine, but that’s not the point - the point is simply that taking the status quo as acceptable is a political position which you’re subjecting others to, and your defence of it to the point of refusing to use software that does not back the status quo doubly so.
Or, in other words, you’re not for getting politics out of software - you’re for getting politics that you don’t agree with out of software.
Well yes, but I would be okay with the same being applied against me. Of course some basic level of politics is necessary (like licenses) if you want to count that as politics.
I won't go and put taxation politics, immigration politics or any other specific politic matters into my code or EULA. I expect this of other software as well. I don't want any unnecessary politics in the software when there clearly is no reason for it.
When I hear Django for example, first thing I think of is the slave from the "Django Unchained" Tarantino movie (or Django Reinhardt, the gypsy musician)...
Maybe this web framework shouldn't name itself after such a famous slave!...
Or from another point of view:
What a dick move was it from Tarantino to name his slave protagonist after such a popular web framework, which tries to be respectful, by avoiding references to slaves.
Also, I'm very much interested in the comment which sparked this thread.
I find it quite freaky, in a 1984-ish way, that it is completely inaccessible now.
What's next, flagging-people?
Burning books is just a few steps away...
You are a bit too trigger happy, maybe...
Well, that's precisely who the framework is named after...
The Django developers try to include the absolutely widest range of people they can. But if that makes people decide to exclude themselves, that's not Django's problem IMO.
I think this is not about inclusion though, this is about exclusion of people who think like me.
And freedom of speech isn't an absolute right – not even in the U.S., but even less so in pretty much any other advanced Western democracy.
When I first started getting into database I found the terminology a little jarring. I know it’s common and the intention is ok, still not a big fan.
But the python community should be ok with renaming things: frankly Lists are just arrays and dictionary’s are hash tables
"don't be afraid to be intellectually honest and say what needs to be said - we're not afraid of hurting people's feelings for the greater good and we're proud of it"
and at the same time
"be careful you don't say anything that could in the slightest be misinterpreted as impugning someone's character"
i feel like i'm taking crazy pills? this is exactly the kind of thing that Nietzsche talked about in geneaology of morals: people in this "community" claim to be above petty politics and egalitarian but as soon as anyone points out anything that even remotely contradicts that image they get silenced or shouted down (e.g. bringing up race or gender politics and their role in the entrepreneur mythology).
it's completely within the scope of productive discourse to point out to someone that they're being irrational because no discourse can proceed until a rational framework is established. case in point: a rational discussion of the merits of django cannot begin from "i'm prejudiced against them because they made questionable PR choices".
honestly there are so few useful discussions on hn. the tech posts are either PR for yc companies or another js vdom framework and the culture posts are all mostly rehashings of the same neoliberal arguments for capital and culture etc. the few people that try to inject any heterogeneity of thought get vilified.
I don't follow your reference to Nietzsche but if it's relevant here, the same point would surely apply to any group. I try not to lose too much sleep over problems with HN that stem from human nature and social dynamics in general. It's hard enough to change the few things we can.
is obvious. what is insidious is the ideology that is preached on almost every controversial thread that papers over that fact.
a selectively enforced set of laws becomes defacto discriminatory and ideological: https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article...
I always opt out if possibly in those scenarios, just as I did with Django. I stopped using it and now I have nothing that runs Django anymore.
1. mediocre routing (no nesting, all routes have to be declared in one place)
2. mediocre middleware (middleware is global)
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
4. custom user model? good luck fighting with Django errors to make that happen
5. custom authentication? external authentication? want a custom token format? want your authentication token in a custom http header? good luck
6. Django is built for 2000s websites not REST/gRPC era
7. want to use graph databases? noSQL? good luck
8. external migration for SQL? oh god, prepare yourself for the mental hell
9. Django as far as I can tell still ONLY supports decoding "x-www-form-urlencoded" bodies, yeah no JSON, it's that pathetic
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)
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.
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)
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?
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:
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.
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.
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.
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 .
4. This hasn't been an issue for some time. See  for how to extend and  how to substitute with your custom model.
5. There are libraries supporting relevant oauth providers  and libraries for specific protocols like ldap . 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  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.
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/customizin...
> 5. custom authentication? external authentication? good luck
No luck needed: 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/
> 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 :)
even though I stopped writing Django for 3 years now but here are some of my reasons as far as I can remember:
5. custom authentication? external authentication? good luck
Django is very intrusive and is pain in the ass in a fast moving environment where you want to use microservices, external authentication/authorization, APIs, gRPC, etc... that's excluding all problems of Python itself. I totally recommend Typescript/Express or Golang for doing any kind of non trivial backend with fast moving environment/requirements currently
Lobbing insults won't hide the fact that you aren't even trying to make a technical argument or otherwise contribute in any way to the discussion:
> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
After that, you followed up with personal attacks and incivility. That's definitely flamewar. You weren't the only one doing it, but that doesn't make it ok.
If someone is wrong, provide correct information and move on. If a comment breaks the guidelines, flag it and move on. In egregious cases, you're welcome to email us at firstname.lastname@example.org. But please don't respond in kind or perpetuate spats.
I've done it both. Our Go + Angular project slaughtered Django and now I was dealing with services running at 25MB RAM with single digit CPU usages instead of the disgusting gluttons that Python and Ruby produces with memory usage measured in GBs. Production servers can have specs rivalling Raspberry PIs instead of IBM Blue Genes. Quite refreshing.
The illusion of power that Django (and all fat frameworks) create works OK if you work with a narrow set of very specific web applications in a static environment with a team of Django specialists. Anything else and the project turns to shit.