4 ms·

> We need a django of the async world I would love to see this, BUT I don't think it's needed to compete with Node.js. Async is mostly interesting for networki

> We need a django of the async world I would love to see this, BUT I don't think it's needed to compete with Node.js. Async is mostly interesting for networking, and you can get that now with Django Channels (https://channels.readthedocs.io/ https://channels.readthedocs.io/) or Pushpin (http://pushpin.org http://pushpin.org (disclosure: I'm the author)). Yeah they rely on separate processes which is a bit of a dodge, but IMHO the separation is good architecture.

sametmax 9y ago
I tried the django channels, and the way it works is a pita. Currently to setup a Django website you usually need a wsgi server, and a font-end server like nginx, then maybe a task queue and now your django channel server. None of them being well integrated. It's crazy. You should have one process that pops and manage the other ones, and allow them to integrate and communicate transparently, with not even a need for nginx/apache for small to medium websites. You should not have to setup a task queue manually, a thread/process pool and the like. You should have a way to communicate real time between the client code, the tasks in your queues, endpoints in your servers and all your workers. You should have synchronization primitives, a common configuration system (with live settings that propagates) and a clean way to build a hierarchy of components. The closest I get is crossbar.io serving django + celery and some custom code to hook them using the WAMP protocol. It's very, very nice, but far away from the integration we should have for those things in 2017. I have been starting to work on something (https://github.com/Tygs https://github.com/Tygs) but since it's a VERY hard problem, I struggle find continuity by working on it only here and there. This is something you need a few months full time to really dig deep. Especially since with async, the HTTP part is actually the easiest part. The hard part is to make it easily usable, configurable and debugable. Maybe there is a kickstarter to build for this.
- amirouche 9y ago
  what about aiohttp? Doesn't it fit to the job of flask/django. A complete stack is one cookiecutter away.
  - sametmax 9y ago
    Tygs is based on aiohttp. But again, aiohttp is very minimalist. You gain very little in productivity if you use only that, and if you don't, well, that's a hell of glue code to write. Being async and capable of dealing with http requests are only the very beginning of the story. With what async allows, we should be able of doing more. Way, way more.

sametmax 9y ago

I tried the django channels, and the way it works is a pita. Currently to setup a Django website you usually need a wsgi server, and a font-end server like nginx, then maybe a task queue and now your django channel server. None of them being well integrated. It's crazy. You should have one process that pops and manage the other ones, and allow them to integrate and communicate transparently, with not even a need for nginx/apache for small to medium websites. You should not have to setup a task queue manually, a thread/process pool and the like. You should have a way to communicate real time between the client code, the tasks in your queues, endpoints in your servers and all your workers. You should have synchronization primitives, a common configuration system (with live settings that propagates) and a clean way to build a hierarchy of components. The closest I get is crossbar.io serving django + celery and some custom code to hook them using the WAMP protocol. It's very, very nice, but far away from the integration we should have for those things in 2017. I have been starting to work on something (https://github.com/Tygs https://github.com/Tygs) but since it's a VERY hard problem, I struggle find continuity by working on it only here and there. This is something you need a few months full time to really dig deep. Especially since with async, the HTTP part is actually the easiest part. The hard part is to make it easily usable, configurable and debugable. Maybe there is a kickstarter to build for this.

amirouche 9y ago
what about aiohttp? Doesn't it fit to the job of flask/django. A complete stack is one cookiecutter away.
- sametmax 9y ago
  Tygs is based on aiohttp. But again, aiohttp is very minimalist. You gain very little in productivity if you use only that, and if you don't, well, that's a hell of glue code to write. Being async and capable of dealing with http requests are only the very beginning of the story. With what async allows, we should be able of doing more. Way, way more.