Feature : django-channel support

[vlordier]

Providing support for Django Channels now included in Django 1.10 instead having django-instant + Centrifugo ?
https://github.com/django/channels
https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django

[synw]

AFAIK django-channels is not integrated into Django yet, and we do not know if it will ever be: from the latest news I've heard (Pycon Australia) nothing is sure, and it might stay separated from Django (which I hope): https://www.youtube.com/watch?v=y2qv5J7PtrA

Honestly I don't like Django channels, and its one of the reasons why I made the django-instant module. I will not do a django-channels implementation myself for django-presence, but I am still open to pull requests for a backend option with django-channels.

[vlordier]

right, it is not in 1.10 yet.
What are the drawbacks of channels vs a centrigo/instant approach ?
My initial thought is that the use of a Go module requires recompiling by the user for each platform, making it a slightly higher barrier to simple integration, while channels supports WebSockets 'out of the box', but I am not aware of tradeoff in performance though.

[synw]

I'll try a little +/- comparison to answer your question:

Channels:

+ Fully integrated with the Django environnement: auth, sessions, etc..
+ Idiomatic more or less official implementation of websockets for Django coded by Django core devs
+ Large community support (but not much modules available: it seems that the Dajngo people are supporting the project but don't really use it in the real world)
+ Secured: you can rely on the battle tested Django authentication

- Needs a change in the stack: you have to use an Awsgi server
- Learning curve: you will have a whole bunch of new concepts to figure out before to start coding something
- Not much scaffolding: you will need to write quite a lot of code to get something to work (but there are some interesting projects to address this, ex: https://github.com/k-pramod/channel.js )

Instant:

+ Backward compatible: you can plug it on any existing project
+ No special concept involved, simple API
+ Usable out of the box: you get the js ready, and even a form to broadcast events immediately. With channels you will have a lot of code to write to achieve that.
+ Performance: Centrifugo is a strong and specialized websockets server, and golang is much more convenient (and nicer to code) than python for this kind of concurrency tasks as it was built from the ground up for concurrency. My opinion is that python async/concurrency is a mess and is slightly more complicated to code than with go for a lower performance. I don't like Celery neither Asyncio.
I did not make any benchmark but it gets really obvious at some point: ex: parsing rss feeds ( https://github.com/synw/jafeed ). There is a small test comparing messages broadcasting in python and go: http://django-instant.readthedocs.io/en/latest/src/install.html#settings : go is double speed.

- Not very Django idiomatic, some golang involved: this might scare some people
- You have to install and use Centrifugo: some people might not want that
- No community, no one knows about it (except you and maybe a few adventurous folks ;)
- Young code

For the go module the binary is available for Linux. For other systems well, who runs a server on Windows or MacOs? For other systems like lets say FreeBSD or OpenBSD I have no doubt that the people operating these have the skills to compile a go module. Note that if you want to avoid go you can still use python to broadcast: there are options for this.

About the "higher barrier to simple integration": this is precisely something I wanted to address with an easy to use module. You don't even have to setup Celery if you use the go module for django-presence. You don't have to learn anything, just install and push some messages right away: they will popup in the browser. So I think the barrier to simple usage is lower in django-instant than in django-channels.

Did you try both, and if yes what is your opinion?

[vlordier]

Great stuff :) Merci ! I will take a look at both approaches, see what works best in terms of speed of setup and performance while in operation.
(re-platform : I use MacOs for dev)