Scribd
Upload
192 views

Django Channels: Synchronous: If An API Call Is Synchronous, It Means That Code Execution Will Block (Or Wait) For

Django Channels extends Django's abilities beyond HTTP to handle protocols like WebSockets. It uses ASGI, which provides an interface for async Python apps. Channels includes consumers that handle incoming events from connections. It uses a channel layer like Redis to allow consumers to communicate asynchronously. This enables features like real-time updates in Django projects.

Uploaded by

Tejas
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
192 views

Django Channels: Synchronous: If An API Call Is Synchronous, It Means That Code Execution Will Block (Or Wait) For

Django Channels extends Django's abilities beyond HTTP to handle protocols like WebSockets. It uses ASGI, which provides an interface for async Python apps. Channels includes consumers that handle incoming events from connections. It uses a channel layer like Redis to allow consumers to communicate asynchronously. This enables features like real-time updates in Django projects.

Uploaded by

Tejas
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Django Channels

Channels is a project that takes Django and extends its abilities beyond HTTP - to handle
WebSocket, chat protocols, IoT protocols, and more. It’s built on a Python specification
called ASGI.
ASGI

ASGI (Asynchronous Server Gateway Interface) is a spiritual successor to WSGI, intended to


provide a standard interface between async-capable Python web servers, frameworks, and
applications.
Synchronous: If an API call is synchronous, it means that code execution will block (or wait) for
the API call to return before continuing. This means that until a response is returned by the API,
your application will not execute any further. Its kind of performance issue in your app.
some times synchronous call do not have performance issue like -if there is code in your app
that will only execute properly once the API response is received.
Asynchronous: Asynchronous calls do not block (or wait) for the API call to return from the
server. Execution continues on in your program, and when the call returns from the server, a
“callback” function is executed.
The important point is that program execution will continue, and asynchronously, the callback
function will be called once program execution completes.
“Real-time” often means a very quick response time from the web/application server. In
modern programming, it is typically accomplished by making a series of non-
blocking asynchronous calls. Most of the popular programming languages are now
supporting asynchronous transactions.
WSGI applications are a single, synchronous callable that takes a request and returns a
response; this doesn’t allow for long-lived connections, like you get with long-poll HTTP or
WebSocket connections.

ASGI is structured as a single, asynchronous callable. It takes  scope , which contains details
about the incoming request,  send , an awaitable that lets you send events to the client,
and  receive , an awaitable which lets you receive events from the client.

This not only allows multiple incoming events and outgoing events for each application, but also
allows for a background coroutine so the application can do other things (such as listening for
events on an external trigger, like a Redis queue).
HTTP connections have a single-request connection scope - that is, your applications will be
instantiated at the start of the request, and destroyed at the end, even if the underlying socket is
still open and serving multiple requests.
Django itself in a synchronous mode but handling connections and sockets asynchronously, and
giving you the choice to write in either style.

Channels is comprised of several packages:

 Channels, the Django integration layer


 Daphne, the HTTP and Websocket termination server
 asgiref, the base ASGI library
 channels_redis, the Redis channel layer backend (optional)

What is a Consumer?
A consumer is the basic unit of Channels code. We call it a consumer as it consumes
events, but you can think of it as its own tiny little application. When a request or new
socket comes in, Channels will follow its routing table - we’ll look at that in a bit - find the
right consumer for that incoming connection, and start up a copy of it.

class ChatConsumer(WebsocketConsumer):

def connect(self):
self.username = "Anonymous"
self.accept()
self.send(text_data="[Welcome %s!]" % self.username)

def receive(self, *, text_data):


if text_data.startswith("/name"):
self.username = text_data[5:].strip()
self.send(text_data="[set your username to %s]" % self.username)
else:
self.send(text_data=self.username + ": " + text_data)

def disconnect(self, message):


pass
Channels allows you to use WebSockets and other non-HTTP protocols in your Django
site. For example you might want to use WebSockets to allow a page on your site to
immediately receive updates from your Django server without using HTTP long-polling
or other expensive techniques.

When Django accepts an HTTP request, it consults the root URLconf to lookup a view
function, and then calls the view function to handle the request. Similarly, when
Channels accepts a WebSocket connection, it consults the root routing configuration to
lookup a consumer, and then calls various functions on the consumer to handle events
from the connection.
Enable a channel layer
A channel layer is a kind of communication system. It allows multiple consumer
instances to talk with each other, and with other parts of Django.

A channel layer provides the following abstractions:

 A channel is a mailbox where messages can be sent to. Each channel has a name.
Anyone who has the name of a channel can send a message to the channel.
 A group is a group of related channels. A group has a name. Anyone who has the name
of a group can add/remove a channel to the group by name and send a message to all
channels in the group. It is not possible to enumerate what channels are in a particular
group.

# Join room group


async_to_sync(self.channel_layer.group_add)(
self.room_group_name,
self.channel_name
)
The async_to_sync(…) wrapper is required because ChatConsumer is a synchronous
WebsocketConsumer but it is calling an asynchronous channel layer method. (All channel layer
methods are asynchronous.)

You might also like