3 ms·

Django's event system lets you avoid polling the DB. Here is a plugin that offers some real-time capability (through a separate process of course): http://tele

Django's event system lets you avoid polling the DB. Here is a plugin that offers some real-time capability (through a separate process of course): http://telegraphy.readthedocs.org/en/latest/django-telegraphy.html http://telegraphy.readthedocs.org/en/latest/django-telegraph... Seems to be the best thing on offer that is off the shelf but you may be better rolling your own node, websocket, redis pub/sub, django integration yourself(which actually isn't that hard to do and may give you better flexibility).

nostrademons 13y ago
If I understand the Telegraph docs correctly, it offers some event-based capability if you interact the app through your Django models exclusively. If, say, you've got a crawler that's out there discovering new content on the web, or a chatbot that listens on IRC, or another app that interacts with the DB via a different framework, you're pretty much out of luck, unless you also write those components to use Telegraph and Django models. That's my point about every part of your system needing to be async-aware. Most off-the-shelf open-source components that people use to build websites now are not. Ironically I think we were in a better position in this respect in the early 2000s with JMS, Jini, JavaSpaces, CORBA, RMI, etc. but all of those fell by the wayside because of justifiable concerns about programming complexity. Now the latest generation of web developers is discovering async soft real-time programming again, and soon we will again discover those concerns about programming complexity.
est 13y ago
> Django's event system lets you avoid polling the DB. Django's signal system must be run on the same instance, synchronously, before returning any response to client. This means if a signal blocks, the response will never reach the client. It's technically impossible to handle post-response events in WSGI. http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-lite.html http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-li... For example, user requests a blog post, you can't first return response then increase your view counter by 1. You just can't. Unless you use some container specific hooks (like uWSGI, Tornado, etc.)
- natrius 13y ago
  Django's signals API is synchronous, but writing a wrapper to process signals as asynchronous tasks is relatively straightforward. https://github.com/nyergler/async-signals https://github.com/nyergler/async-signals
  - est 13y ago
    > Async Signals uses Celery_ for signal routing Since Celery is just a bunch of worker processes, why can't we build a web framework which natively supports both web worker and bg task worker?
    - natrius 13y ago
      Sounds good to me.

nostrademons 13y ago

If I understand the Telegraph docs correctly, it offers some event-based capability if you interact the app through your Django models exclusively. If, say, you've got a crawler that's out there discovering new content on the web, or a chatbot that listens on IRC, or another app that interacts with the DB via a different framework, you're pretty much out of luck, unless you also write those components to use Telegraph and Django models. That's my point about every part of your system needing to be async-aware. Most off-the-shelf open-source components that people use to build websites now are not. Ironically I think we were in a better position in this respect in the early 2000s with JMS, Jini, JavaSpaces, CORBA, RMI, etc. but all of those fell by the wayside because of justifiable concerns about programming complexity. Now the latest generation of web developers is discovering async soft real-time programming again, and soon we will again discover those concerns about programming complexity.

est 13y ago

> Django's event system lets you avoid polling the DB. Django's signal system must be run on the same instance, synchronously, before returning any response to client. This means if a signal blocks, the response will never reach the client. It's technically impossible to handle post-response events in WSGI. http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-lite.html http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-li... For example, user requests a blog post, you can't first return response then increase your view counter by 1. You just can't. Unless you use some container specific hooks (like uWSGI, Tornado, etc.)

natrius 13y ago
Django's signals API is synchronous, but writing a wrapper to process signals as asynchronous tasks is relatively straightforward. https://github.com/nyergler/async-signals https://github.com/nyergler/async-signals
- est 13y ago
  > Async Signals uses Celery_ for signal routing Since Celery is just a bunch of worker processes, why can't we build a web framework which natively supports both web worker and bg task worker?
  - natrius 13y ago
    Sounds good to me.