Hacker News Reader

Comment by avinassh | Hacker News Reader

> and a nightmare to work around when you need to do something it doesn't easily support.

Can you elaborate more on this? And also for what kind of apps one should avoid Django?

Nightmarish (without building additional systems): Asynchronous operations (i.e. any task that takes place after you return a response), anything involving websockets or long poll responses, anything involving cross-client communication through the server (like chat). Intelligent master/slave DB routing for read-only queries.

Hard: Using any DB but PostgreSQL. You can use other DBs, but Django silently disables features. Doing anything with the DB that isn't directly managed by Django itself. Doing anything but basic pre-defined URL routing as supported by their routing system.

Use something else: Not using a relational DB as a backend. Not using their user management and authentication system. If you want to use something other than their built-in ORM, templating, and routing.

I personally recommend Flask in the cases where Django is not a good fit. A threading/forking fastcgi model with basic nginx caching is incredibly performant. That said, Flask is pretty terrible at most of the "nightmare" level tasks as well.

Are you familiar with django channels?

https://blog.heroku.com/in_deep_with_django_channels_the_fut...

They supposed to make this sort of thing easy and straightforward. I'm still learning them, but this system seems to be well designed and makes a lot of sense.

Django + Django REST Framework + React should give you pretty much everything you need to build whatever you want, including single page apps. At least as far as I understand it.

Channels don't guarantee at-least-once delivery, so you can only use them at best as a refinement - you have to assume your clients will miss messages. Which makes it unusable for many use cases (though I'm sure many negligently ignore it too).

In my experience, celery handles the asynchronous tasks pretty well (and with minimal configuration) For web-sockets, yes django is a (or was) a nightmare to work with. I had to use nodejs and django with a common redis backend to implement chat functionality (not fun at all).

I have high hopes from django-channels and the asgi server. Hopefully, we will get plug and play asynchronous chat apps for django in the future.

Like any omni-tool Django can usually solve most problems a web application framework can be applied to. Depending on your problem space however you might need to pull out a crow bar or a blow torch.

Leaving the metaphor, python in general fails at some async and cpu-intensive tasks, while other languages (or even frameworks/libraries of Python) excel at it. Whatsapp for example excelled through its use of Erlang, and would not have worked well had it been build with Django.

Django always gets a lot of praise here (deservedly) but I feel a counter-weight should also be applied to prevent less experienced, and easily influenced, developers from getting the wrong impression (though that may be a lost cause with tech hype).

Expecting that implementing a message router works well in a general-purpose, synchronous web framework is... I dunno. It just isn't.

Anything involving asynchronous operations has historically been painful with Django. I know that new versions are improving on this, but I think for now it's limited to web sockets.

That has little do with Django; you'll find it's the same with any WSGI based framework, because WSGI is fundamentally a synchronous interface.

True, but it's still worth calling out since Django is a WSGI-based framework.

How about using Celery and sending tasks to it? A customer of mine has a Django application which is little more that a web interface over a bunch of long running Celery tasks and it works pretty well.

No status updates over websockets, but it could be added pretty easily.

Earlier this year I worked on a project which did exactly this. I find it much more difficult to get insight into the system with Celery & RabbitMQ than with other tools. I also found Celery's documentation to not be super awesome for my uses, and it took a lot of trial and error to get it running. YMMV of course.

Celery is indeed great, but the doc falls far behind django's. The "celery+django" doc is actually outdated in a couple of places, and getting it setup isn't such a breeze.

I regret not having documented what I did at the time to actually push an update to this. :(

Also look into django-channels

For example if you have a very special user model or you need object level permissions. Django supports to customize the user model to some extend and you can integrate an object level permission system, but depending on your needs Djangos ORM could hinder you and/or you would have to abolish some of the out of the box functionality of Django.

I was recently surprised that Django can handle object level permissions very nicely. The support is built in, but nit implemented in Django itself, but you can simply use django-guardian and everything just works.

when you need to deal with extreme amount of data with a small latency that comes from the database than django is not that pleasent, at least not it's orm.

It very much depends. The ORM in Django is one of the better ones, and very powerful. If it doesn't suffice it still offers query wrapping. Of course, if you need to process all 1 bazillion records in application code, then you're going to take a huge speed hit with any framework/ORM and language. Processing data at the storage site (the DB server) is simply very, very efficient.

When lots of objects are loaded then annotations usually improve performance greatly, since they avoid the "for x in y: query_database" execution, instead executing a single query with allr equired data.

well reordering 1000 objects in scala/java is fast or doing map/flatmap/filter or put them into a map, however with django orm it's not. not a problem in python tough since when you directly use pg from python it retuns a iterator which is faster when you directly put everything correctly in your list. problem with django orm is that it copies it into a list structure etc. pp. (at least pre 1.4)

Well, you're probably going to be looking for something other than Python in the first place if latency is such a major issue. Python can be fast enough to handle most use cases, but really low latency is not one of its strengths.

Often these requirements are exaggregated. "Real" low latency applications are far harder to write than just changing a language or framework. It would mean, for example, to forego any allocations in critical req-resp paths, or exactly bounded runtime of processing. Note how most software that is perceived to be "low latency" doesn't do any of that (eg. audio/video streaming)

Reply on news.ycombinator.com