Django Channels VS Django 3.0 / 3.1?

today I'm using Django 2.2, and I'd like to add WebSocket support to my project.

If you want to add websocket support to your app, at the moment you don't need to upgrade to django 3.0. Django 2.2 plus channels can do that - and for the time being is the best way forward. (Although there's absolutely no harm in upgrading to django 3.0 if you don't have any good reason not to). I will try and further explain why in this answer.

From what I understood, Django-Channels is a project that have been started outside of Django, and then, started to be integrated in the core Django. But the current state of this work remains confusing to me.

Yes, my understanding is that channels started out as a project from one of the core Django developers (Andrew Godwin - who has also been instrumental in bringing about the async changes brought in Django 3.0). It is not included automatically if you just install Django, but it is officially part of the django project, and has been since september 2016 (see here). It's now on version 2.4 and so is an established and stable project that can be used to add websockets to your django app.

So What's going on with Django 3.x and async?

Whilst channels adds a way to add some async functionality to your django app, Django at it's core is still synchonous. The 'async' project that is being gradually introduced addresses this. The key thing to note here is that it's being introduced gradually. Django is made up of several layers:

• WSGI server (not actually part of django): deals with the protocol of actually accepting an HTTP request
• Base Handler: This takes the request passed to it from the server and makes sure it's sent through the middleware, and the url config, so that we end up with a django request object, and a view to pass it to.
• The view layer (which does whatever you tell it to)
• The ORM, and all the other lovely stuff you get with Django, that we can call from the view.

Now to fully benefit from async, we really need all of these layers to be async, otherwise there won't really be any performance benefit. This is a fairly big project, hence why it is being rolled out gradually:

• With the release of django 3.0, all that was really added was the ability to talk to an ASGI sever, (rather than just a WSGI one).
• When Django 3.1 is released (expected august 2020) it is anticipated that there will be capabilities for asynchronous middleware and views.
• Then finally in django 3.2, or maybe even 4.0 we will get async capabilities up and down the whole of Django.

Once we get to that final point, it may be worth considering using the async features of Django for stuff like web-sockets, but at the moment we can't even take advantage of the fact we can now deal with ASGI as well as WSGI servers. You can use Django with an ASGI server, but there would be no point as the base handler is still synchronous.

TLDR

• Django channels adds a way to deal with protocols other than HTTP, and adds integrations into things such as django's session framework and authentication framework, so it's easy to add things like websockets to your django project. It is complete and you can start working with it today!!.
• Native async support is a fundemental re-write of the core of Django. This is a work in progress. It's very exciting, but won't be ready to really benefit from for a little while yet.

There was a good talk given at last years djangoCon outlining the plans for async django. You can view it here.