Pour fêter la sortie de Django 3.0, j'ai essayé ASGI, le successeur spirituel de WSGI, mais le socket Web n'a pas fonctionné.

Fête! Django 3.0 est sorti!

02/02/2019 Django 3.0 est sorti. Django 1.0 est sorti en 2008 et 2.0 en décembre 2017. Et la version 3.0 est sortie le 2 décembre de cette année. Il a fallu environ 10 ans pour passer de 1 à 2, mais c'était une vitesse surprenante de moins de 2 ans de 2 à 3. Qu'est-ce que j'ai fait ces deux dernières années par rapport à ça? Jetons maintenant un œil aux nouvelles fonctionnalités qui me tiennent à cœur dans Django 3.0!

Qu'est-ce que le support ASGI?

J'étais curieux à ce sujet. Cela dit, je n'ai jamais touché à l'ASGI et l'ai officiellement soutenu! Même si on me l'a dit, c'était comme ça. Mais j'ai WSGI-san ... Cependant, quand je l'ai recherché, il m'a semblé que l'ASGI semblait être quelque chose qui ne pouvait être ignoré.

Selon la Note de publication, la fonction asynchrone n'est pas actuellement dans WSGI et n'est prise en charge que lorsqu'elle est exécutée dans ASGI. (Mais pensez-vous que nous le soutiendrons à l'avenir?). Officiel ASGI dit: "ASGI est le successeur spirituel du WSGI (suite spirituelle. wiki /% E7% B2% BE% E7% A5% 9E% E7% 9A% 84% E7% B6% 9A% E7% B7% A8)) ". De cette façon, WSGI, qui semblait être mon allié fort, semble être rétrocompatible avec ASGI.

Ce n'est pas grave, mais le mot «suite spirituelle» est cool. Il semble que Xenosaga pour Xenogias, Perfect Dark pour Golden Eye 007, etc. y correspondent. Cependant, WSGI et ASGI ne sont pas des jeux ou des œuvres de fiction, et la suite est-elle vraiment adaptée? J'ai pensé, alors je vais le lire comme un successeur spirituel. Je l'ai écrit dans le titre.

Essayez d'exécuter Django avec ASGI

Si c'était décidé, l'histoire serait rapide, alors j'ai essayé d'exécuter Django avec ASGI. Créez un environnement avec Docker.

sudo docker run --rm -it -p 8000:8000 python:3.8 bash

J'utilise python3.8. À propos, Django 3.0 prend en charge python 3.6, 3.7 et 3.8.

pip install django daphne

Installez daphne avec django. daphne ressemble à un serveur pour ʻASGI. Le ʻu WSGI dans le WSGI est probablement le daphné dans le ʻASGI`. sûrement. À propos, daphné semble s'appeler daphné. Même si django est un django, le d de daphné doit être prononcé correctement.

django-admin startproject app
cd app
daphne -b 0.0.0.0 -p 8000 app.asgi:application

Après l'installation, créez un projet et essayez de l'exécuter immédiatement.

Hourra! déplacé! Fini!

Cela a fonctionné, mais je ne sais pas ce qui me rend heureux. Oui bien sur. Même si la fonction asynchrone est à vendre, elle ne communique que de manière synchrone.

N'y a-t-il pas un tutoriel comme la création d'une application de chat qui vous permet d'essayer la communication asynchrone avec Django?

était. https://channels.readthedocs.io/en/latest/tutorial/index.html Lorsque les canaux Django sont utilisés, il semble que le socket Web puisse être utilisé avec Djang, et il existe un didacticiel d'application de chat poli. C'est mon âme d'essayer d'exécuter une application de chat créée en copiant ceci avec daphne. Cependant, je ne suis pas sûr de la relation entre les canaux Django et ce support ASGI. Eh bien, mais n'allez pas trop loin car vous pourriez le découvrir en l'utilisant.

Placez le produit fini créé selon le tutoriel ici ici. J'essaierai de le déplacer. Il est dans l'état command: python manage.py runserver 0.0.0.0: 8000.

sudo docker-compose up -d

J'ai confirmé l'opération avec 2 fenêtres, mais je peux utiliser le chat correctement.

Maintenant, déplaçons cela avec daphne. Réécrivez «command» comme suit:

 services:
     app:
         build: .
-        command: python manage.py runserver 0.0.0.0:8000
+        command: daphne -b 0.0.0.0 -p 8000 mysite.asgi:application
         volumes:
             - .:/srv
         ports:

Cela devrait fonctionner comme je m'y attendais ...

sudo docker-compose down
sudo docker-compose up -d

Hmm, ça ne marche pas.

Quand je lis le message d'erreur, il dit que websocket ne peut pas être utilisé.

172.17.0.1:52480 - - [06/Dec/2019:07:36:28] "GET /chat/a/" 200 1413
172.17.0.1:52488 - - [06/Dec/2019:07:36:28] "WSCONNECTING /ws/chat/a/" - -
2019-12-06 07:36:29,471 ERROR    Exception inside application: Django can only handle ASGI/HTTP connections, not websocket.
  File "/usr/local/lib/python3.8/site-packages/daphne/cli.py", line 30, in asgi
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.8/site-packages/django/core/handlers/asgi.py", line 144, in __call__
    raise ValueError(
  Django can only handle ASGI/HTTP connections, not websocket.
172.17.0.1:52488 - - [06/Dec/2019:07:36:29] "WSDISCONNECT /ws/chat/a/" - -

Jetons un coup d'œil autour de la ligne 144 de asgi.py.

    async def __call__(self, scope, receive, send):
        """
        Async entrypoint - parses the request and hands off to get_response.
        """
        # Serve only HTTP connections.
        # FIXME: Allow to override this.
        if scope['type'] != 'http':
            raise ValueError(
                'Django can only handle ASGI/HTTP connections, not %s.'
                % scope['type']
            )

Il semble qu'il lève une exception lorsqu'il ne s'agit pas de connexions HTTP. Qu'est-ce que c'est que ça?

• Le support ASGI ne prend pas encore en charge la prise Web
• L'idée d'essayer d'exécuter l'application de chat du didacticiel des canaux django avec daphne app.asgi: application en utilisant Django 3.0 est fausse en premier lieu

Je pense que c'est non plus, mais je ne suis pas sûr. Le mystère ne fait que s'approfondir. Cependant, il est officiellement déclaré que ASGI peut prendre en charge Django de manière asynchrone, je continuerai donc à y porter une attention particulière.

fin

Au revoir WSGI. J'ai ASGI ...