13 ms·
Real-Time Django: Get Started with Django Channels
- deleted 11y ago[deleted]
- collinmanderson 11y agoIt's great to see Django getting first class support for real-time. I remember building a hacked-together real-time chat 10 years ago using Python using ajax, but I haven't done much since. I'll have to check it out.
- cdelsolar 11y agoThis sounds amazing! Very excited to give it a try. I am working on a side project that I wanted to add real-time capabilities to and I'm not very happy about my Go + Django hybrid solution.
- adaline 11y agoI assume this also means support for Rails 5's ActionCable.
- DanFeldman 11y agoDoes this replace Celery+RabbitMQ/Queue service?
- jaxondu 11y agoFrom the article: "Remember: Channels is a general-purpose utility for running background tasks. Thus, many features that used to require Celery or Python-RQ could be done using Channels instead. Channels can’t replace dedicated task queues entirely: it has some important limitations, including at-most-once delivery, that don’t make it suitable for all use cases. Still, Channels can make common background tasks much simpler. For example, you could easily use Channels to perform image thumbnailing, send out emails, tweets, or SMSes, run expensive data calculations, and more."
- mrfusion 11y agoSo what can't it do that celery does?
- izak30 11y agoCelery does a ton of things that channels doesn't currently do. Celery has a lot of workflow concepts built in (Chains, Chords, etc). Celery also has prioritization, and a fairly robust ecosystem that channels may take a while to deliver.
- zeemonkee3 11y agoI'd like to see an example of that vs. using celery.
- cdnsteve 11y agoNice to see Django moving forward but is still backwards friendly. Love that. "Channels is to become a built-in feature for Django 1.10, but in order to aid adoption and to encourage community usage and support, it will also be backported to Django 1.8 and 1.9 via a third-party app." ASGI seems to be a very important piece of this. "Despite the name of the proposal, ASGI does not specify or design to any specific in-process async solution, such as asyncio, twisted, or gevent. Instead, the receive_many function can be switched between nonblocking or synchronous. This approach allows applications to choose what’s best for their current runtime environment; further improvements may provide extensions where cooperative versions of receive_many are provided."
- bliti 11y agoThis is great news. Django is a great web dev tool and having websockets support is icing on the cake. I guess this adds more weight to the thought I've been having: That Web applications are moving away from MVC and more into messaging layers. Front end JS frameworks have pushed things to be this way. Which brings the Web into a pseudo native environment of sorts. Anyhow, will be happily tinkering with this from today onwards.
- jessegreathouse 11y agoThe good news is that it's "real-time Django". The bad news is that it's Django.
- yadascript 11y agoWhy?
- jessegreathouse 11y agoPython is a language that gives us a lot of liberty in how we solve problems, but Django is a set of cookie cutters for doing things a certain way. Django's cookie cutter patterns and extensions don't lend themselves well to doing things outside the way that Django intended them to. It's why a lot of us prefer Flask or Pyramid as framework of choice. http://nando.oui.com.br/2014/04/04/why_i_sort_of_dislike_django.html http://nando.oui.com.br/2014/04/04/why_i_sort_of_dislike_dja...
- ubernostrum 11y agoI think the objection is referring to Django unequivocally as "bad news", rather than saying that your personal preference is for Flask. (I work in a shop which has used both, and generally try to avoid claiming one or the other is objectively better; they're not quite at the apples-and-oranges level, but pretty close)
- jessegreathouse 11y ago
- spriggan3 11y agoI did some Django years ago and if I remember correctly Django wasn't a "server" ie long running process but more like CGI. So how does it work exactly ? is there some python code running as a demon polling socket events and interacting with the actual Django app ?
- nostrademons 11y agoDjango is agnostic about its actual connection to the webserver. It provides a basic wsgi adapter (wsgi is the Python spec for delivering HTTP requests to an app and sending responses back to the client), which can be plugged into any wsgi container. When HTTP requests arrive at the wsgi container, it forwards them on to Django's entry point, which runs the normal routes/views/middleware/etc. When I first got into Django in 2007 the preferred container was flup, using an scgi connection to the webserver. Nowadays, it seems like uwsgi over HTTP is preferred. CGI was an option for deployment since inception, but I don't know anyone that actually ran their Django apps over CGI, since it's many times slower than using uwsgi. Django Channels extends wsgi into asgi (ASynchronous Gateway Interface), which provides both send() and receive_many() callables to the application server. In other words, Django can now send messages, unsolicited, back to the webserver, which presumably has a websocket connection back to the browser.
- samcheng 11y agoDjango generally relies on the WSGI standard to separate the 'server' from the (Django) 'application' - this allows Django to run on a number of different server implementations. https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
- deleted 11y ago[deleted]
- ubernostrum 11y agoThe underlying model for all Python Web apps -- WSGI -- is CGI-like. But the actual deployment of WSGI almost always involves a long-running process or processes, which keep the application code in memory and then expose the appropriate WSGI API to whatever Web server you're using. Switching that from "expose WSGI API" to "expose ASGI API" gets you Channels :)
- 616c 11y agoHere is a good interview with WSGI/Django devs talking about the rationale and starting work on the Django Channels project. http://pythonpodcast.com/wsgi-2.html http://pythonpodcast.com/wsgi-2.html
- zokier 11y agoThe big question is if other frameworks will adopt this ASGI/Channels model also, or will it remain a Django-specific thing.
- bkovacev 11y agoI love the chat implementation. What would the other possible usage scenarios be?
- cdelsolar 11y agoA real time game using websockets e.g.
- jMyles 11y agoI surmise that hendrix, based on Twisted, will be the first true ASGI / Django Channels backend.
- retrogradeorbit 11y agoThe problem with Twisted is that everything needs to be rewritten for it, like a special snowflake. Hendrix is an example of that. The advantage of Django is you can use any python library without issues.
- jMyles 11y agoReally? I have exactly the opposite impression: that Twisted is happy to consume any streams of data you provide, while Django is only happy if you comply with the dictates of the LazySettings object. In any case, I think you'll find hendrix unbelievably easy to use - here's a talk that gives some detail: https://www.youtube.com/watch?v=92VeMkjM1TQ https://www.youtube.com/watch?v=92VeMkjM1TQ
- ubernostrum 11y agoI think you may be talking past each other. If 100% of integration with the system consists of sending network requests to it and receiving network responses from it, then sure, it's not going to affect you much. But when your integration involves taking existing applications/libraries and having them share memory space and call into and be called by functions in Twisted, then you're looking at a different story. Asynchronous code is infectious -- unless everything in your codebase is written to be or play nice with async, you get no benefits from the async parts and in fact can often get a net harm as the async and non-async bits clash with each other.
- retrogradeorbit 11y agoThis is not about async in general. This is about twisted's approach to async. For instance, there are numerous other languages that handle async elegantly and all the libraries work and there are no special snowflakes. Go comes to mind. Asyncio in python is a better answer for Python. But twisted is not asyncio. Twisted remains it's own separate thing.
- sciurus 11y agoTo get more insight into the design of channels, see (my coworker!) Andrew Godwin's article "Laying the Channels Groundwork" at http://www.aeracode.org/2016/1/3/laying-channels-groundwork/ http://www.aeracode.org/2016/1/3/laying-channels-groundwork/
- hamiltonkibbe 11y agoCan we come up with a new word for this? Real-Time has a definition w/r/t computing, and it's certainly not "Python code, running in a C runtime, on top of a non-realtime OS."
- zokier 11y agoThat ship sailed almost 10 years ago, the complaints now are getting bit tired. Words occasionally take on new meanings, live with it.
- hamiltonkibbe 11y agoYes, but the ship was guaranteed to sail no later than 8 years ago. Meanwhile, I'm still waiting for the blog post to load.
- LyndsySimon 11y agoI'd refer to it as just "asynchronous". I'm not sure why they felt the need to redefine.
- zokier 11y agoAJAX was already async (that's where the first A comes from..), so it makes sense to have new name for new generation
- mozumder 11y agoDoes Nginx support ASGI? What's the recommended production ASGI web server?
- Wilya 11y agoThe recommended ASGI server seems to be Daphne[0]. Nginx doesn't need to speak ASGI natively (as it doesn't speak WSGI natively), more likely Daphne would replace the WSGI server (gunicorn, etc) running behind nginx. [0] https://github.com/andrewgodwin/daphne/ https://github.com/andrewgodwin/daphne/
- leoh 11y agoI am consistently impressed with the thoughtful API abstractions django develops. They were a little late to the game on this — you had to use other libraries to do WebSockets for a while. But they did this right.
- Walkman 11y agomaybe it is possible to be more specific and say "I am consistently impressed with the thoughtful API abstractions Andrew Godwin develops". There are other great Django developers of course, but he is just insanely good.
- acdha 11y agoI think part of what he's insanely good at is carefully soliciting feedback from other people, particularly those with a lot of experience with similar but distinct problems. The final spec goes back close to a year (https://www.aeracode.org/2015/6/17/beyond-request-response/ https://www.aeracode.org/2015/6/17/beyond-request-response/ https://groups.google.com/d/topic/django-developers/mt1mTNvc0Ew/discussion https://groups.google.com/d/topic/django-developers/mt1mTNvc...) and the polish really shows. I think of that as a “senior developer” skill which is easy to underestimate since it doesn't directly translate into tons of commits but is so critical to the long-term success of a project.
- lolosso 11y agoWay to go DJANGO
- uryga 11y agoChannels sound pretty similar to Observables/Streams/Signals from the reactive world. Weird that they didn't mention it.
- andkon 11y agoFrom what I understand, Channels' provenance is from Go (scroll down to the What is a Channel? section): http://channels.readthedocs.org/en/latest/concepts.html http://channels.readthedocs.org/en/latest/concepts.html
- retrogradeorbit 11y ago"Go channels are reasonably similar to Django ones" Really? Only at a surface glance. Having used channels in both Go and in Clojure, I would say they are nothing like Django channels. The only thing they share is they are like a fifo pipe. In Go and Clojure channels are an in-process async construct. They have nothing to do with the network at all. (There may be libraries that expose their network connections in the language as channels, but the channel itself is completely in process). In these languages there is no 'routing' that needs to be set up. There is no 'linearisation' problem. They are first class and can be passed in and out of functions. Also most importantly, pulling from or pushing to a channel appear to the programmer as a blocking operation, while under the hood the language inverts control to create a non-blocking situation. Send and receive on the Django channels look to be non-blocking and appear to the programmer to be non-blocking (correct me if I'm wrong, please). Saying all this I'm not opposed to calling Django channels, channels. Channels is a generic term, and what is being done here in Django can be very much described as a channel. Just remember that they are actually very different to the "channels" as used in Go.
- ucefkhc 11y agoMeteor knowns all of this hhh Django is just getting into the new tech :P
- ucefkhc 11y agoWell Django is outdated since it has just been catching up with websocket :P Meteor has that like 3 years ago :D
- travjones 11y agoThis is great news. For those with flask apps, check out flask-socket[0] for websocket support. [0]: https://github.com/kennethreitz/flask-sockets https://github.com/kennethreitz/flask-sockets
- thatgibbyguy 11y agoI'm someone who moved to django from meteor (for work) and at first I was shocked at how similar they were, but after that I was shocked at how out-dated django seemed. Websockets was just one of those issues so it's good to see it addressed. However, with meteor's DDP there's still no comparison. Looking ahead to Reactive GraphQL that meteor is working on, django seems to be permanently one step behind for the foreseeable future. These are just my opinions, but overall definitely great news for django developers.
- zeemonkee3 11y agoSo does meteor support SQL backends yet (not talking unsupported plugins or whatever MDG is promising to do Real Soon Now). If it's still tightly coupled to MongoDB then there is zero chance I can see it being used for anything more serious than an MVP or hackathon project by a company with non-trivial data requirements.
- tim333 11y agoMeteor's DDP only can have it's annoyances as well. It's ok till you want to do something like upload a photo which it's not great for.
- uptownJimmy 11y agoMeteor is pretty unfit for prime time app development. They might one day hoist it over the fence, but for right now it remains a nice idea, I think. For one thing, there were some regrettable architectural decisions made from the start: MongoDB just don't cut it. If my company tried to sell apps built with Meteor and/or MongoDB to corporate clients, we'd be waiting tables and working construction for a living. But there are other issues there, perhaps even philosophical ones. I've become disheartened at what I see happening in the JavaScript arena. Change and never-ending-newness are distorting the reality field there. It's all shiny churn, frothy and irrational.
- picozeta 11y agoThe best thing about Django is its documentation. It is one of the best (if not _the_ best) documented projects I have ever used. Example: Let's say you are reading about Django authentication related stuff and somebody links for further clarification to https://docs.djangoproject.com/en/1.7/topics/auth/default/ https://docs.djangoproject.com/en/1.7/topics/auth/default/. Bam! You immediately know it's outdated (emphasized by the headline) and switch to https://docs.djangoproject.com/en/1.9/topics/auth/default/ https://docs.djangoproject.com/en/1.9/topics/auth/default/. This might seem minor, but I highly appreciate such attention to detail. And I really like the official page's layout, look and feel which concentrates on information, rather than stupid, flashy animations. Ha, looks like I'm getting old.
- uptownJimmy 11y agoAbsolutely in agreement. I am 2 years into my app dev career, all of it spent pushing .NET around in the enterprise. But I need to expand my skill set, I need to continue working remote, and I'm interested in OSS in general. Honestly, Python and Django seem like heaven compared to the other language/framework ecosystems I investigated. Not gonna name any names there... But the documentation for Python and Django is A++. It's just really, really good. I can't praise it enough. The whole setup is elegant, intelligent and accessible. I really appreciate that.
- wikibob 11y agoI'm in a bit of the same boat lately, deciding between updating my skills to the treadmill of JS frameworks, or Rails 5, or Django. Have you found any good leads on Django remote work?
- uptownJimmy 11y agoI did a cursory survey, and saw that remote Django jobs existed, but I didn't do any due diligence. I figured I'd learn the stack first. ;) My rough impression is that Rails remote jobs are relatively thick on the ground, but that any OSS dev stack will be better represented in remote job postings than any enterprise stack. So since I prefer Python to Ruby, and Django to Rails, I figured I'd take a leap of faith. JavaScript is simply not going to be my main dish, not for the time being. Things are just too crazy there. I don't have time to play whack-a-mole with my career skill set.
- pritambarhate 11y agoIt's great that Dijago Channels will allow a developer to use same framework and ORM to build the WebSocket based applications. However I think from the deployment and scaling plan, it's better to keep HTTP / REST servers separate from the Web Socket servers. Both models scale differently. So keeping them on different infrastructure would allow to scale those 2 systems independent of each other.
- danpalmer 11y agoAs far as I can tell, they are. In production you'll run your WSGI servers for the HTTP/REST side of things, your "ASGI" servers (with daphne) for the websockets side of things, and your workers, all separately. That should mean that each can be scaled pretty much independently.