Hi Collin, I'll answer in this thread to keep here things tidy.
Since Server-Sent Events are just HTTP you can scale them the same way you scale your normal web app. Split users so some users hit one server and some users hit another. Then let Django communicate with all server processes instead of just one. But I wouldn't say this would have to be the responsibility of Django, just like scaling your database isn't Django's concern. As long as you can decide who connects to what machine it should be able to scale horizontally. /Emil On Saturday, 30 May 2015 19:04:26 UTC+2, Collin Anderson wrote: > > Hi Emil, > > I also like "server sent events" (EventSource). They get through proxies > much more reliably than WebSockets. :) > > "You would start the process separately, add a script tag to your page, > and all clients that connected to the page would be connected to the > process. Now Django could push messages through that process as part of the > request-response cycle, and all clients would be notified. Other processes > (a cron job?) could do the same." > > Have you thought about how to scale this across multiple machines? > > Thanks, > Collin > > > On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote: >> >> Hi! >> >> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with >> the title "Why Django Sucks". The idea was to follow in the footsteps of >> great conference talks like these: >> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 >> >> These talks are great because they encourage people to take an outside, >> critical, perspective of Django and where it's going. >> >> My talk was well received, with many both interested and skeptical >> questions afterwards. Unfortunately, the final video was missing the >> sound, so the camera crew is working on fixing that now. I'll post it to >> this thread as soon as I get it. Meanwhile, here's a text summary: >> >> --- >> >> The theme for my talk was that Django's bad support for Javascript heavy >> sites. Everyone is using javascript for their sites nowadays. Problem >> is, Django (and large parts if the Django community) has long had a >> approach to Javascript that can be summed up with Simon Willison's reply >> to someone asking for AJAX support in 2005: >> >> "For me "Ajax support" really is pure marketing fluff - as far as I'm >> concerned EVERY web framework supports Ajax unless it does something >> truly moronic like refuse to let you output documents that don't have >> the standard header/footer template." >> Source: http://bit.ly/django2005 >> >> The problem with this mindset (I'm not picking at Simon from 10 years >> ago) is that the web as large is moving towards MORE javascript, with >> live notifications, live updating templates, and reusable template >> components. And these are hard to implement in Django as things work >> today. I see this is the biggest competitive disadvantage Django has >> going forward. >> >> So, what specific features am I proposing? I will get to a specific set >> of features soon. But first I want to make clear that a completely >> different set of features could get us to the same goal. That is: it's >> possible to agree on the broader goal for Django, and disagree on my >> specific set of features. If you don't agree on the features, I would >> love to see your proposed feature list. >> >> Just to give one alternate path: In that old thread from 2005, Jacob >> Kaplan-Moss suggested exposing the ORM through Javascript with an RPC >> API: >> https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J >> >> Jacobs suggestion is interesting, but I have three other features that I >> would like to discuss. I think they would greatly ease building >> javascript heavy sites with Django. >> >> *I will split the specific suggestions into three different e-mail >> threads, so we can discuss them separately*. >> >> Here's a short intro to them: >> >> 1. Template Components >> React.js popularized the notion that in front-end development, code >> organization should be based on interface components, not split up into >> HTML, Javascript and CSS. It's simply a different way to organize the >> code for your front-end, that I strongly think Django should make >> easier. (read more in separate thread) >> >> 2. Support a client side template language >> The multiple template engine work has made it possible to switch out >> Django Templates with another engine. One of the most powerful things >> this enables is to use a template language that is executable both on >> the server and client. This means you can do the same kind of live >> updates to your page that the Meteor.js people are doing, and just >> re-render parts of the DOM as a direct result of a database update. >> (read more in separate thread) >> >> 3. Support Server-Sent Events >> If you want a snappy user experience, polling isn't enough. There are >> two major ways to get out of the request-response cycle. Namely: >> websockets and server-sent events. Server-Sent Events have a much >> simpler protocol, and could be implemented with asyncio (no external >> dependencies except for backwards compatibility) in a performant way. It >> would be a great reason to choose Django over other frameworks. (read >> more in separate thread) >> >> --- >> >> This is not a "request for features". I am in no way saying that I think >> you should build things for me. Instead I'm willing to work on them >> together with anyone interested, if these are features that the core >> team would be interested in. >> >> But first I would like to see if you: >> 1. Agree on the main point that Django should do more for javascript >> heavy sites. >> 2. Agree that one or more of the specific features that I'm proposing >> would be a good fit for Django (see separate threads). >> >> No matter what, I would love to hear your thoughts and ideas here. >> >> Regards, >> >> Emil Stenström >> Twitter: @EmilStenstrom >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/05e0406d-15a6-41f2-8168-ca8b507d4e6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
