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.
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.
Node.JS, on one-hand seems to take the approach of Go-lang - standard libraries that do basic web-handling well, but on the other hand, I think it is tarnished by Javascript's reputation for having too many third-party packages, too many options, new framework every week, etc.
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: https://docs.djangoproject.com/en/2.2/ref/models/querysets/#...
(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.
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)
https://instagram-engineering.com/web-service-efficiency-at-...
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.
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?
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.
- 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
* manage.py
* project/settings.py
* project/urls.py
* 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.
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.
$ 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.
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.
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.
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.
uwsgi --plugin=python3,http,router_static,router_cache --mime-file /etc/mime.types --offload-threads '%k' --file-serve-mode x-accel-redirect --route '^/static/.* addheader:Cache-Control: public, max-age=7776000' --static-map $STATIC_ROOT=$STATIC_URL --static-gzip-all --cache2 'name=statcalls,items=100' --static-cache-paths 86400 --static-cache-paths-name statcalls"
EDIT: even though I stopped writing Django for 3 years now but 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. 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? 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
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
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.
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)[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/
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?
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 [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/#incl...
[2] https://docs.djangoproject.com/en/2.2/topics/db/sql/
[3] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...
[4] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...
[5] https://python-social-auth-docs.readthedocs.io/en/latest/con...
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 :)
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!
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.
If I use a javascript server framework, I believe that it will prevent me to duplicate forms validation code (in server in frontend) and also easier for SSR (Server Side Rendering). But Django is a robust framework, in my beloved Python language, why should I still use it?
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[2] that uses Django's validators[3] along with Transcrypt to share validation logic between the server and a `ModelForm`.
I thought it was a neat way to centralize validation logic.
[1] http://www.transcrypt.org/
[2] https://github.com/johnfraney/django-front-end-validators
Also a fan of these:
https://wsvincent.com/ (and his books are excellent)
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.
I'm an experienced ReactJS developer and I discovered Django after ReactJS and I am finding myself developing new projects not with React but just with plain Django/JavaScript/HTML. That's because of the nature of my projects of course which are simple crud applications, but the point is that for simple applications, Django makes things incredibly easy and fast and importantly, easy to understand.
More sophisticated user interfaces I would definitely build in React of course.