Outils tiers

1. Exporter les jeux

L’objectif est de créer un fichier CSV contenant tous les jeux, leurs questions et leurs réponses. Chaque ligne correspond à une réponse ; les données relatives à la question et au jeu associés sont donc répétées.

Deux approches sont possibles : partir des questions et remonter les relations définies par les clés étrangères pour retrouver le jeu, ou partir du jeu et parcourir les relations jusqu’aux questions.

Dans notre exemple, nous souhaitons réutiliser les sérialiseurs ; nous allons donc mettre en œuvre la seconde approche. Cette contrainte volontaire permet d’illustrer la réutilisation de composants dans des contextes différents.

Enfin, dans notre script, nous voulons pouvoir extraire un seul jeu. Nous allons donc permettre de passer ce dernier en paramètre.

Voici le début du code :

import csv 
  
from django.core.management.base import BaseCommand 
from django.utils.translation import gettext_lazy as gettext 
  
from app.models import Game 
from app.serializers import GameSerializer 
  
  
class Command(BaseCommand): 
    help = gettext("Export Games to CSV") 
  
    def add_arguments(self, parser): 
        # Add optional "game_name" argument to filter export by game name 
        parser.add_argument( 
            "—game-name", 
            type=str, 
            help=gettext("Export data for a specific game (by name)"), 
        ) 
  
    def handle(self, *args, **kwargs): 
        game_name = kwargs.get("game_name", None) 
        data = []  

Pour créer une commande, nous devons créer un fichier...

1. Qu’est-ce qu’un middleware ?

Django permet d’écrire des applications web, qui fonctionnent en utilisant le protocole HTTP. Le client envoie une requête HTTP au serveur et le serveur lui renvoie une réponse.

Mais quel est le parcours de cette requête dans Django ?

La requête atteint d’abord le serveur d’application : le serveur de développement de Django pendant le développement, ou un serveur tel que Gunicorn dans certains environnements de test ou de production. Selon le déploiement, elle est transmise à Django au moyen d’une interface WSGI ou ASGI.

La requête traverse ensuite les middlewares déclarés dans la propriété MIDDLEWARE du fichier de configuration. Chacun peut effectuer un prétraitement et, par exemple, associer à la requête l’utilisateur déduit des données de session. Un middleware peut également interrompre la chaîne de traitement : en l’absence d’un jeton CSRF valide pour une requête qui l’exige, le middleware concerné renvoie directement une réponse d’erreur.

Une fois ceci fait, elle passe par le processus de routage, dont l’objectif est de déduire de l’URL la vue à utiliser.

Une fois la vue déterminée, Django l’exécute....

1. Nouveaux conteneurs

Celery est une file de tâches distribuée. Lorsqu’une application doit exécuter un traitement long, elle peut déléguer ce travail à un processus distinct plutôt que de bloquer la réponse HTTP. L’application enregistre les informations nécessaires, publie une tâche dans une file, puis un worker l’exécute de manière asynchrone.

Le traitement n’est donc plus exécuté par le serveur web, mais par un composant distinct. L’application Django publie un message contenant les informations utiles ; un worker Celery consomme ensuite les messages et exécute les tâches à mesure qu’ils arrivent.

Nous ajouterons également un composant supplémentaire dont le but est de permettre le lancement de tâches planifiées. L’exemple typique serait, par exemple, d’attendre quelques jours lorsqu’un jeu atteint le statut final done, puis de le supprimer.

Voici ces nouveaux conteneurs. Pour commencer, nous allons utiliser un broker, c’est-à-dire un outil permettant de transmettre des messages entre applications :

  tuto_django_rabbitmq: 
    container_name: tuto_django_rabbitmq 
    image: rabbitmq:management 
    ports: 
      - "5672:5672" 
      - "15672:15672" 
    environment: 
      - RABBITMQ_DEFAULT_USER=guest 
      - RABBITMQ_DEFAULT_PASS=guest 
      - RABBITMQ_LOGS=- 
    healthcheck: 
      test: rabbitmq-diagnostics -q ping 
      interval: 30s 
      timeout: 10s 
      retries: 3  

Deux ports sont partagés. Le premier correspond au port que nous pouvons écouter pour recevoir ou transmettre des messages. Le second correspond au port d’un outil permettant de configurer le service. Ainsi, nous pourrons ouvrir http://localhost:15672 dans un navigateur...