Django is an awesome web framework for python and does a really good job, either for building websites or web APIs using Rest Framework. One area where it usually fell short was dealing asynchronous functionality, it wasn’t its original purpose and wasn’t even a thing on the web at the time of its creation.
The world moved on, web-sockets became a thing and suddenly there was a need to handle persistent connections and to deal with other flows “instead of” (or along with) the traditional request-response scheme.
In the last few years there has been several cumbersome solutions to integrate web-sockets with Django, some people even moved to other python solutions (losing many of the goodies) in order to be able to support this real-time functionality. It is not just web-sockets, it can be any other kind of persistent connection and/or asynchronous protocol in a microservice architecture for example.
Of all alternatives the most developer friendly seems to be django-channels, since it lets you keep using familiar django design patterns and integrates in a way that seems it really is part of the framework itself. Last year django-channels saw the release of it second iteration, with a completely different internal design and seems to be stable enough to start building cool things with it, so that is what we will do in this post.
Webhook logger
In this blog post I’m gonna explore the version 2 of the package and evaluate how difficult it can be to implement a simple flow using websockets.
Most of the tutorials I find on the web about this subject try to demonstrate the capabilities of “channels” by implementing a simple real-time chat solution. For this blog post I will try something different and perhaps more useful, at least for developers.
I will build a simple service to test and debug webhooks (in reality any type of HTTP request). The functionality is minimal and can be described like this:
- The user visits the website and is given a unique callback URL
- All requests sent to that callback URL are displayed on the user browser in real-time, with all the information about that request.
- The user can use that URL in any service that sends requests/webhooks as asynchronous notifications.
- Many people can have the page open and receive at the same time the information about the incoming requests.
- No data is stored, if the user reloads the page it can only see new requests.
In the end the implementation will not differ much from those chat versions, but at least we will end up with something that can be quite handy.
Note: The final result can be checked on Github, if you prefer to explore while reading the rest of the article.
Setting up the Django project
The basic setup is identical to any other Django project, we just create a new one using django_admin startproject webhook_logger and then create a new app using python manage.py startapp callbacks (in this case I just named the app callbacks).
Since we will not store any information we can remove all database related stuff and even any other extra functionality that will not be used, such as authentication related middleware. I did this on my repository, but it is completely optional and not in the scope of this small post.
Installing “django-channels”
After the project is set up we can add the missing piece, the django-channels package, running pip install channels==2.1.6. Then we need to add it to the installed apps:
INSTALLED_APPS = [
"django.contrib.staticfiles",
"channels",
]
For this project we will use Redis as a backend for the channel layer, so we need to also install the channels-redis package and add the required configuration:
CHANNEL_LAYERS = {
"default": {
"BACKEND": "channels_redis.core.RedisChannelLayer",
"CONFIG": {"hosts": [(os.environ.get("REDIS_URL", "127.0.0.1"), 6379)]},
}
}
The above snippet assumes you are running a Redis server instance on your machine, but you can configure it using a environment variable.
Add websocket’s functionality
When using “django channels” our code will not differ much from a standard django app, we will still have our views, our models, our templates, etc. For the asynchronous interactions and protocols outside the standard HTTP request-response style, we will use a new concept that is the Consumer with its own routing file outside of default urls.py file.
So lets add these new files and configurations to our app. First inside our app lets create a consumer.py with the following contents:
# callbacks/consumers.py
from channels.generic.websocket import WebsocketConsumer
from asgiref.sync import async_to_sync
import json
class WebhookConsumer(WebsocketConsumer):
def connect(self):
self.callback = self.scope["url_route"]["kwargs"]["uuid"]
async_to_sync(self.channel_layer.group_add)(self.callback, self.channel_name)
self.accept()
def disconnect(self, close_code):
async_to_sync(self.channel_layer.group_discard)(
self.callback, self.channel_name
)
def receive(self, text_data):
# Discard all received data
pass
def new_request(self, event):
self.send(text_data=json.dumps(event["data"]))
Basically we extend the standard WebsocketConsumer and override the standard methods. A consumer instance will be created for each websocket connection that is made to the server. Let me explain a little bit what is going on the above snippet:
- connect – When a new websocket connection is made, we check which callback it desires to receive information and attach the consumer to the related group ( a group is a way to broadcast a message to several consumers)
- disconnect – As the name suggests, when we lose a connection we remove the “consumer” from the group.
- receive – This is a standard method for receiving any data sent by the other end of the connection (in this case the browser). Since we do not want to receive any data, lets just discard it.
- new_request – This is a custom method for handling data about a given request/webhook received by the system. These messages are submitted to the group with the type
new_request.
You might also be a little confused with that async_to_sync function that is imported and used to call channel_layer methods, but the explanation is simple, since those methods are asynchronous and our consumer is standard synchronous code we have to execute them synchronously. That function and sync_to_async are two very helpful utilities to deal with these scenarios, for details about how they work please check this blog post.
Now that we have a working consumer, we need to take care of the routing so it is accessible to the outside world. Lets add an app level routing.py file:
# callbacks/routing.py
from django.conf.urls import url
from .consumers import WebhookConsumer
websocket_urlpatterns = [url(r"^ws/callback/(?P<uuid>[^/]+)/$", WebhookConsumer)]
Here we use a very similar pattern (like the well known url_patterns) to link our consumer class to connections of certain url. In this case our users could connect to an URL that contains the id (uuid) of the callback that they want to be notified about new events/requests.
Finally for our consumer to be available to the public we will need to create a root routing file for our project. It looks like this:
# <project_name>/routing.py
from channels.routing import ProtocolTypeRouter, URLRouter
from callbacks.routing import websocket_urlpatterns
application = ProtocolTypeRouter({"websocket": URLRouter(websocket_urlpatterns)})
Here we use the ProtocolTypeRouter as the main entry point, so what is does is:
It lets you dispatch to one of a number of other ASGI applications based on the type value present in the scope. Protocols will define a fixed type value that their scope contains, so you can use this to distinguish between incoming connection types.
Django Channels Documentation
We just defined the websocket protocol and used the URLRouter to point to our previous defined websocket urls.
The rest of the app
At this moment we are able to receive new websocket connections and send to those clients live data using the new_request method on the client. However at the moment we do not have information to send, since we haven’t yet created the endpoints that will receive the requests and forward their data to our consumer.
For this purpose lets create a simple class based view, it will receive any type of HTTP request (including the webhooks we want to inspect) and forward them to the consumers that are listening of that specific uuid:
# callbacks/views.py
class CallbackView(View):
def dispatch(self, request, *args, **kwargs):
channel_layer = get_channel_layer()
async_to_sync(channel_layer.group_send)(
kwargs["uuid"], {"type": "new_request", "data": self._request_data(request)}
)
return HttpResponse()
In the above snippet, we get the channel layer, send the request data to the group and return a successful response to calling entity (lets ignore what the self._request_data(request) call does and assume it returns all the relevant information we need).
One important piece of information is that the value of the type key on the data that is used for the group_send call, is the method that will be called on the websocket’s consumer we defined earlier.
Now we just need to expose this on our urls.py file and the core of our system is done.
# <project_name>/urls.py
from django.urls import path
from callbacks.views import CallbackView
urlpatterns = [
path("<uuid>", CallbackView.as_view(), name="callback-submit"),
]
The rest of our application is just standard Django web app development, that part I will not cover in this blog post. You will need to create a page and use JavaScript in order to connect the websocket. You can check a working example of this system in the following URL :
http://webhook-logger.ovalerio.net
For more details just check the code repository on Github.
Deploying
I not going to explore the details about the topic of deployments but someone else wrote a pretty straightforward blog post on how to do it for production projects that use Django channels. You can check it here.
Final thoughts
With django-channels building real-time web apps or projects that deal with other protocols other than HTTP becomes really simple. I do think it is a great addition to the current ecosystem, it certainly is an option I will consider from now on for these tasks.
Have you ever used it? do you any strong opinion about it? let me know on the comments section.
Final Note: It seems based on recent messages on the mailing list that the project might suspend its developments in its future if it doesn’t find new maintainers. It would definitely be a shame, since it has a lot of potential. Lets see how it goes.