14👍
There are many interesting concepts behind your question which need clarification.
Let’s start with WebSocket usage first.
WebSocket
WebSocket might very well be your primary interest in using Django Channels since Django alone just manages HTTP.
For that, you don’t need Channel Layers, nor a running worker.
In development, this is what you normally see starting a standard Django project:
$ python manage.py runserver
Performing system checks...
...
Django version 2.1.5, using settings 'djlistener.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
However, adding channels to INSTALLED_APPS and defining the ASGI_APPLICATION setting as suggested by the Django Channels documentation, you’ll notice a slightly different output:
$ python manage.py runserver
Performing system checks...
...
Django version 2.1.5, using settings 'djlistener.settings'
Starting ASGI/Channels version 2.1.6 development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
That’s because the Channels’ development server has taken over from the Django development server, and you can immediately start using both HTTP and WebSocket communications.
In production:
-
You can choose to use Daphne for both HTTP and WebSockets requests since Daphne will auto-negotiate between HTTP and WebSocket.
-
Or, you can split HTTP and WebSocket traffic: running standard HTTP requests through a WSGI server, and using Daphne (or uvicorn) only for things WSGI cannot do like WebSockets, HTTP long-polling, or other IoT protocols.
References:
-
Django channel’s documentation: HTTP and WebSocket
Channel Layers
Channel Layers are an entirely optional part of Channels as of version 2.0.
They provide an abstraction that allows you to talk between different instances of an application for several purposes.
How? When you send a message, it is received by the consumers listening to the group or channel on the other end.
My primary motivation for using Channel Layers is the Group concept, which lets me broadcast a message to all WebSocket clients registered (upon connection) to a specific group. For that purpose, I don’t need a worker: I send my message to the group with channel_layer.group_send(), and Channels Layer delivers it to the Consumers, which in turn send it to the WebSocket client.
Worker and Background Tasks
A very specific use of Channel Layers is that of delegating some work to a set of worker servers listening on fixed channel names, as a simple task queue.
Here (and only here) is where the runworker command comes in.
Most often you’ll use other well-known solutions like Celery or Django-rq for this; but on some occasions, this might be a cheap and very-low-latency alternative for a simple background tasks queue.
References: