Hi folks (and especially Andrew): I've just completed writing an example Channels app [1] for an article about Channels [2]. Overall it was a super-pleasant experience: Channels seems pretty solid, the APIs make sense to me, and I couldn't be more excited about the new things this'll let me do!
In the interests of making this thing as solid as possible before we merge it into Django, I do have some feedback on some of the hiccups I encountered. Roughly in order of severity (as I perceive it), they are: 1. Debugging errors: I found debugging errors that happen in a consumer to be *really* difficult -- errors mostly presented as things just silently not working. It took a ton of messing around with logging setups before I could get anything of use dumped to the console. This isn't strictly a Channels issue (I've noted similar problems with AJAX views and errors in Celery tasks), but I think Channels sorta brings the issue to a head. I think we need some better defaults, and simple, clear documentation, to make sure that exceptions go somewhere useful. 2. Static files: I had trouble getting static files served. I'm used to using Whitenoise ( http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites that don't need a proper static server, but of course it doesn't work with Channels since Channels doesn't use WSGI! I found the (undocumented) StaticFilesConsumer ( https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8), but that feels less than ideal. I think this might be an opportunity, however. If Daphne learns how to serve static files (perhaps via optional integration with Whitenoise?), this would actually make static media in Django a bit easier by default. [I would be happy to work on this if I get a thumbsup.] 3. WebSocket routing: Channels routes all WebSocket connections to a single set of consumers (the `websocket.*` consumers). This means that if you want multiple WebSocket URLs in a single app you need to manually parse the path. And, to make things more complicated, you only get the WebSocket path passed in the connection message, so you have to also use a channel session to keep track. This feels like a distinct step back from the URL routing we already have in Django, and it was surprising to me to have to do this by hand. It definitely felt like Channels is missing some sort of WebSocket URL router. I had a brief chat with Andrew, who indicates that he'd planned for this to be a post-1.0 feature. I'm not sure I agree - it feels pretty fundamental - but I'd like to hear other thoughts. [This is another thing I'd be interested in working on, assuming a thumbs.] --- Has anyone else here played with Channels? Are there other things I'm missing that might need to be included before we merge this? Jacob [1] https://github.com/jacobian/channels-example [2] https://blog.heroku.com/archives/2016/3/17/in_deep_with_django_channels_the_future_of_real_time_apps_in_django ? -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK8PqJFq9VRFSFtco5%2B7C8fA90wC4TcYU8affqD3NTaV4AP6VQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
