Uso de Django Signals para simplificar y desacoplar el c贸digo

    Introducci贸n

    Los sistemas se vuelven m谩s complejos a medida que pasa el tiempo y esto justifica la necesidad de desacoplar m谩s los sistemas. Un sistema desacoplado es m谩s f谩cil de construir, extender y mantener a largo plazo, ya que el desacoplamiento no solo reduce la complejidad del sistema, sino que cada parte del sistema se puede administrar individualmente. La tolerancia a fallas tambi茅n ha mejorado ya que, en un sistema desacoplado, un componente defectuoso no arrastra todo el sistema con 茅l.

    Django es un poderoso marco web de c贸digo abierto que se puede usar para construir sistemas grandes y complejos, as铆 como peque帽os. Sigue el patr贸n arquitect贸nico modelo-plantilla-vista y es fiel a su objetivo de ayudar a los desarrolladores a lograr la entrega de aplicaciones basadas en web basadas en datos complejos.

    Django nos permite desacoplar la funcionalidad del sistema creando aplicaciones separadas dentro de un proyecto. Por ejemplo, podemos tener un sistema de compras y tener aplicaciones separadas que manejen cuentas, env铆o de recibos por correo electr贸nico y notificaciones, entre otras cosas.

    En tal sistema, es posible que se necesiten varias aplicaciones para realizar una acci贸n cuando ocurren ciertos eventos. Un evento puede ocurrir cuando un cliente realiza un pedido. Por ejemplo, necesitaremos notificar al usuario por correo electr贸nico y tambi茅n enviar el pedido al proveedor o vendedor, al mismo tiempo podremos recibir y procesar pagos. Todos estos eventos suceden al mismo tiempo y, dado que nuestra aplicaci贸n est谩 desacoplada, necesitamos mantener todos los componentes sincronizados, pero 驴c贸mo lo logramos?

    Las se帽ales de Django son 煤tiles en tal situaci贸n, todo lo que debe suceder es que se env铆e una se帽al cuando un usuario realiza un pedido, y cada componente relacionado o afectado lo escucha y realiza sus operaciones. Exploremos m谩s sobre las se帽ales en esta publicaci贸n.

    Se帽ales de un vistazo

    Las se帽ales de Django son una implementaci贸n del patr贸n Observer . En tal patr贸n de dise帽o, se implementa un mecanismo de suscripci贸n donde m煤ltiples objetos est谩n suscritos u “observando” un objeto en particular y cualquier evento que pueda ocurrirle. Una buena analog铆a es c贸mo todos los suscriptores de un canal de YouTube reciben una notificaci贸n cuando un creador de contenido carga contenido nuevo.

    A trav茅s de un “despachador de se帽ales”, Django puede distribuir se帽ales en una configuraci贸n desacoplada a los “receptores” registrados en los diversos componentes del sistema. Las se帽ales se registran y activan cada vez que ocurren ciertos eventos, y cualquier oyente de ese evento ser谩 notificado de que el evento ha ocurrido, adem谩s de recibir algunos datos contextuales dentro de la carga 煤til que pueden ser relevantes para la funcionalidad del receptor. Un receptor puede ser cualquier funci贸n o m茅todo de Python. M谩s sobre esto m谩s adelante.

    Aparte del despachador de se帽ales, Django tambi茅n incluye algunas se帽ales 煤tiles que podemos escuchar. Incluyen:

    • post_save, que se env铆a cada vez que se crea y guarda un nuevo modelo de Django. Por ejemplo, cuando un usuario se registra o sube una publicaci贸n nueva,
    • pre_delete, que se env铆a justo antes de eliminar un modelo de Django. Un buen escenario ser铆a cuando un usuario est谩 eliminando un mensaje o su cuenta,
    • request_finished, que se activa cada vez que Django completa el servicio de una solicitud HTTP. Esto puede variar desde abrir el sitio web o acceder a un recurso en particular.

    Otra ventaja de Django es que es un marco altamente personalizable. En nuestro caso, podemos crear nuestras se帽ales personalizadas y utilizar el sistema integrado para enviarlas y recibirlas en nuestro sistema desacoplado. En la secci贸n de demostraci贸n, nos suscribiremos a algunas de las se帽ales integradas de Django y tambi茅n crearemos algunas personalizadas propias.

    Pero primero, veamos un ejemplo r谩pido que utiliza Django Signals. Aqu铆 tenemos dos funciones que juegan ping-pong entre s铆, pero interact煤an a trav茅s de se帽ales:

    from django.dispatch import Signal, receiver
    
    # Create a custom signal
    ping_signal = Signal(providing_args=["context"])
    
    class SignalDemo(object):
        # function to send the signal
        def ping(self):
            print('PING')
            ping_signal.send(sender=self.__class__, PING=True)
    
    # Function to receive the signal
    @receiver(ping_signal)
    def pong(**kwargs):
        if kwargs['PING']:
            print('PONG')
    
    demo = SignalDemo()
    demo.ping()
    

    En este sencillo script hemos creado una clase con un m茅todo para enviar la se帽al y una funci贸n separada fuera de la clase que recibir谩 y responder谩. En nuestro caso, el emisor de la se帽al enviar谩 el PINGcomando junto con la se帽al, y la funci贸n del receptor comprobar谩 si el PINGcomando est谩 presente e imprimir谩 PONGcomo respuesta. La se帽al se crea con la Signalclase de Django y es recibida por cualquier funci贸n que tenga el @receiverdecorador.

    La salida del script:

    $ python signal_demo.py
    
    PING
    PONG
    

    Normalmente, tendr铆amos que invocar la pong()funci贸n desde dentro de la ping()funci贸n, pero con se帽ales podemos obtener una soluci贸n similar pero desacoplada. La pong()funci贸n ahora puede residir en otro proyecto de archivo y a煤n responder a nuestra PINGse帽al.

    Cu谩ndo usar se帽ales

    Ya hemos identificado qu茅 son las se帽ales de Django y c贸mo funcionan, pero como ocurre con cualquier otra caracter铆stica del marco, no est谩 destinado a ser utilizado en todo momento. Hay escenarios particulares en los que se recomienda encarecidamente que usemos se帽ales de Django, e incluyen:

    • Cuando tenemos muchas piezas de c贸digo separadas interesadas en los mismos eventos, una se帽al ayudar铆a a distribuir la notificaci贸n del evento en lugar de que invoquemos todas las diferentes piezas de c贸digo en el mismo punto, lo que puede desordenarse e introducir errores.
    • Tambi茅n podemos usar se帽ales de Django para manejar interacciones entre componentes en un sistema desacoplado como alternativa a la interacci贸n a trav茅s de mecanismos de comunicaci贸n RESTful
    • Las se帽ales tambi茅n son 煤tiles cuando se extienden bibliotecas de terceros donde queremos evitar modificarlas, pero necesitamos agregar funcionalidad adicional

    Ventajas de las se帽ales

    Django Signals simplifica la implementaci贸n de nuestros sistemas desacoplados de varias formas. Nos ayudan a implementar aplicaciones reutilizables y, en lugar de volver a implementar la funcionalidad de forma individual, o modificar otras partes del sistema, podemos simplemente responder a las se帽ales sin afectar a otros c贸digos. De esta manera, los componentes de un sistema se pueden modificar, agregar o eliminar sin tocar la base de c贸digo existente.

    Las se帽ales tambi茅n proporcionan un mecanismo simplificado para mantener los diferentes componentes de un sistema desacoplado sincronizados y actualizados entre s铆.

    Proyecto de demostraci贸n

    En nuestro proyecto de demostraci贸n, crearemos un tablero de trabajos simple donde los usuarios acceder谩n al sitio, ver谩n los trabajos disponibles y elegir谩n una publicaci贸n de trabajo para suscribirse. Los usuarios se suscribir谩n simplemente enviando su direcci贸n de correo electr贸nico y ser谩n notificados de cualquier cambio en el trabajo. Por ejemplo, si los requisitos cambian, la vacante se cierra o si se elimina la oferta de trabajo. Todos estos cambios ser谩n realizados por un administrador que tendr谩 un panel para crear, actualizar e incluso eliminar las ofertas de trabajo.

    Con el 谩nimo de desvincular nuestra aplicaci贸n, crearemos la aplicaci贸n principal de Jobs Board y una aplicaci贸n de notificaciones separada que tendr谩 la tarea de notificar a los usuarios cuando sea necesario. Luego usaremos se帽ales para invocar la funcionalidad en la aplicaci贸n Notificaciones desde la aplicaci贸n principal de Jobs Board.

    Otro testimonio del amplio conjunto de funciones de Django es el panel de administraci贸n integrado que nuestros administradores usar谩n para administrar los trabajos. Nuestro trabajo en ese frente se reduce considerablemente y podemos crear prototipos de nuestra aplicaci贸n m谩s r谩pido.

    Configuraci贸n del proyecto

    Es una buena pr谩ctica construir proyectos de Python en un entorno virtual para que trabajemos en un entorno aislado que no afecte la configuraci贸n de Python del sistema, por lo que usaremos Pipenv.

    Primero configuremos nuestro entorno:

    # Set up the environment
    $ pipenv install --three
    
    # Activate the virtual environment
    $ pipenv shell
    
    # Install Django
    $ pipenv install django
    

    Django viene con algunos comandos que nos ayudan a realizar diversas tareas como crear un proyecto, crear aplicaciones, migrar datos y probar c贸digo, entre otras. Para crear nuestro proyecto:

    # Create the project
    $ django-admin startproject jobs_board && cd jobs_board
    
    # Create the decoupled applications
    $ django-admin startapp jobs_board_main
    $ django-admin startapp jobs_board_notifications
    

    Los comandos anteriores crear谩n un proyecto Django con dos aplicaciones dentro de 茅l, que est谩n desacopladas entre s铆 pero que a煤n pueden funcionar juntas. Para confirmar que nuestra configuraci贸n fue exitosa, migremos las migraciones predeterminadas que vienen con Django y configuremos nuestra base de datos y tablas:

    $ python manage.py migrate
    $ python manage.py runserver
    

    Cuando accedemos a la instancia de ejecuci贸n local de nuestro proyecto Django, deber铆amos ver lo siguiente:

    Esto significa que hemos configurado nuestro proyecto Django con 茅xito y ahora podemos comenzar a implementar nuestra l贸gica.

    Implementaci贸n

    Django se basa en un patr贸n de arquitectura modelo-vista-plantilla, y este patr贸n tambi茅n guiar谩 nuestra implementaci贸n. Crearemos modelos para definir nuestros datos, luego implementaremos vistas para manejar el acceso y manipulaci贸n de datos y finalmente plantillas para mostrar nuestros datos al usuario final en el navegador.

    Para tener nuestras aplicaciones integradas en la aplicaci贸n principal de Django, tenemos que agregarlas jobs_board/settings.pydebajo INSTALLED_APPS, de la siguiente manera:

    INSTALLED_APPS = [
        # Existing apps remain...
    
        # jobs_board apps
        'jobs_board_main',
        'jobs_board_notifications',
    ]
    

    Parte 1: La aplicaci贸n Main Jobs Board

    Aqu铆 es donde residir谩 la mayor parte de la funcionalidad de nuestro sistema y ser谩 el punto de interacci贸n con nuestros usuarios. Contendr谩 nuestros modelos, vistas y plantillas y algunas se帽ales personalizadas que usaremos para interactuar con la aplicaci贸n Notificaciones.

    Comencemos creando nuestros modelos en jobs_board_main/models.py:

    # jobs_board_main/models.py
    
    class Job(models.Model):
        company = models.CharField(max_length=255, blank=False)
        company_email = models.CharField(max_length=255, blank=False)
        title = models.CharField(max_length=255, blank=False)
        details = models.CharField(max_length=255, blank=True)
        status = models.BooleanField(default=True)
        date_created = models.DateTimeField(auto_now_add=True)
        date_modified = models.DateTimeField(auto_now=True)
    
    class Subscriber(models.Model):
        email = models.CharField(max_length=255, blank=False, unique=True)
        date_created = models.DateTimeField(auto_now_add=True)
        date_modified = models.DateTimeField(auto_now=True)
    
    class Subscription(models.Model):
        email = models.CharField(max_length=255, blank=False, unique=True)
        user = models.ForeignKey(Subscriber, related_name="subscriptions", on_delete=models.CASCADE)
        job = models.ForeignKey(Job, related_name="jobs", on_delete=models.CASCADE)
        date_created = models.DateTimeField(auto_now_add=True)
        date_modified = models.DateTimeField(auto_now=True)
    

    Creamos un modelo para definir nuestra Jobpublicaci贸n, que solo tendr谩 el nombre de la empresa y los detalles del trabajo junto con el estado de la oferta de trabajo. Tambi茅n tendremos un modelo para almacenar nuestros suscriptores tomando solo sus direcciones de correo electr贸nico. Los suscriptores y los trabajos se unen a trav茅s del Subscriptionmodelo donde almacenaremos los detalles de las suscripciones a las ofertas de trabajo.

    Con nuestros modelos en su lugar, necesitamos realizar migraciones y migrarlos para tener las tablas creadas en la base de datos:

    $ python manage.py makemigrations
    $ python manage.py migrate
    

    A continuaci贸n, pasamos a la secci贸n de vista de nuestra aplicaci贸n. Creemos una vista para mostrar todas las ofertas de trabajo y otra para mostrar las ofertas de trabajo individuales donde los usuarios pueden suscribirse enviando sus correos electr贸nicos.

    Comenzaremos creando la vista que manejar谩 la visualizaci贸n de todos nuestros trabajos:

    # jobs_board_main/views.py
    
    from .models import Job
    
    def get_jobs(request):
        # get all jobs from the DB
        jobs = Job.objects.all()
        return render(request, 'jobs.html', {'jobs': jobs})
    

    Para este proyecto usaremos vistas basadas en funciones, siendo la alternativa las vistas basadas en clases, pero eso no es parte de esta discusi贸n. Consultamos la base de datos para todos los trabajos y respondemos a la solicitud especificando la plantilla que representar谩 los trabajos y tambi茅n incluyendo los trabajos en la respuesta.

    Django viene con el motor de plantillas Jinja que usaremos para crear los archivos HTML que ser谩n presentados al usuario final. En nuestra jobs_board_mainaplicaci贸n, crearemos una templatescarpeta que albergar谩 todos los archivos HTML que presentaremos a los usuarios finales.

    La plantilla para representar todos los trabajos mostrar谩 todos los trabajos con enlaces a publicaciones de trabajos individuales, de la siguiente manera:

    <!-- jobs_board_main/templates/jobs.html -->
    <!DOCTYPE html>
    <html>
      <head>
        <title>Jobs Board Homepage</title>
      </head>
      <body>
        <h2> Welcome to the Jobs board </h2>
    
        {% for job in jobs %}
          <div>
            <a href="/jobs/{{ job.id }}">{{ job.title }} at {{ job.company }}</a>
            <p>
              {{ job.details }}
            </p>
          </div>
        {% endfor %}
    
      </body>
    </html>
    

    Hemos creado el Jobmodelo, la get_jobsvista para obtener y mostrar todas las vistas y la plantilla para representar la lista de trabajos. Para unir todo este trabajo, tenemos que crear un punto final desde el cual los trabajos ser谩n accesibles, y lo hacemos creando un urls.pyarchivo en nuestro jobs_board_main_application:

    # jobs_board_main/urls.py
    
    from django.urls import path
    from .views import get_jobs
    
    urlpatterns = [
        # All jobs
        path('jobs/', get_jobs, name="jobs_view"),
    ]
    

    En este archivo, importamos nuestra vista, creamos una ruta y le adjuntamos nuestra vista. Ahora registraremos las URL de nuestras aplicaciones en el urls.pyarchivo principal de la jobs_boardcarpeta del proyecto:

    # jobs_board/urls.py
    
    urlpatterns = [
        path('admin/', admin.site.urls),
        path('', include('jobs_board_main.urls')), # <--- Add this line
    ]
    

    Nuestro proyecto est谩 listo para ser probado ahora. Esto es lo que obtenemos cuando ejecutamos la aplicaci贸n y navegamos a localhost:8000/jobs:

    Actualmente no tenemos puestos de trabajo. Django viene con una aplicaci贸n de administraci贸n que podemos usar para realizar nuestra entrada de datos. Primero, comenzamos creando un superusuario:

    Con el superusuario creado, necesitamos registrar nuestros modelos en el admin.pyarchivo de nuestra jobs_board_mainaplicaci贸n:

    # jobs_board_main/admin.py
    from django.contrib import admin
    from .models import Job
    
    # Register your models here.
    admin.site.register(Job)
    

    Reiniciamos nuestra aplicaci贸n y navegamos localhost:8000/admine iniciamos sesi贸n con las credenciales que acabamos de configurar. Este es el resultado:

    Cuando hacemos clic en el signo m谩s en la fila “Trabajos”, obtenemos un formulario en el que completamos los detalles sobre nuestra publicaci贸n de trabajo:

    Cuando guardamos el trabajo y navegamos de regreso al jobspunto final, somos recibidos por la publicaci贸n de trabajo que acabamos de crear:

    Ahora crearemos las vistas, las plantillas y las URL para mostrar un solo trabajo y tambi茅n permitiremos que los usuarios se suscriban enviando su correo electr贸nico.

    Nuestro jobs_board_main/views.pyse ampliar谩 de la siguiente manera:

    # jobs_board_main/views.py
    # previous code remains
    def get_job(request, id):
        job = Job.objects.get(pk=id)
        return render(request, 'job.html', {'job': job})
    
    def subscribe(request, id):
        job = Job.objects.get(pk=id)
        sub = Subscriber(email=request.POST['email'])
        sub.save()
    
        subscription = Subscription(user=sub, job=job)
        subscription.save()
    
        payload = {
          'job': job,
          'email': request.POST['email']
        }
        return render(request, 'subscribed.html', {'payload': payload})
    

    Tambi茅n necesitaremos crear la plantilla para una vista 煤nica de una publicaci贸n de trabajo en templates/job.html, que incluye el formulario que tomar谩 el correo electr贸nico de un usuario y lo suscribir谩 a la publicaci贸n de trabajo:

    <!-- jobs_board_main/templates/job.html -->
    <html>
      <head>
        <title>Jobs Board - {{ job.title }}</title>
      </head>
      <body>
          <div>
            <h2>{{ job.title }} at {{ job.company }}</h2>
            <p>
              {{ job.details }}
            </p>
            <br>
            <p>Subscribe to this job posting by submitting your email</p>
            <form action="/jobs/{{ job.id }}/subscribe" method="POST">
              {% csrf_token %}
              <input type="email" name="email" id="email" placeholder="Enter your email"/>
              <input type="submit" value="Subscribe">
            </form>
            <hr>
          </div>
      </body>
    </html>
    

    Una vez que un usuario se suscribe a un trabajo, necesitaremos redirigirlo a una p谩gina de confirmaci贸n cuya subscribed.htmlplantilla ser谩 la siguiente:

    <!-- jobs_board_main/templates/subscribed.html -->
    <!DOCTYPE html>
    <html>
      <head>
        <title>Jobs Board - Subscribed</title>
      </head>
      <body>
          <div>
            <h2>Subscription confirmed!</h2>
            <p>
              Dear {{ payload.email }}, thank you for subscribing to {{ payload.job.title }}
            </p>
          </div>
      </body>
    </html>
    

    Finalmente, nuestra nueva funcionalidad deber谩 exponerse a trav茅s de puntos finales que agregaremos a nuestro existente de la jobs_board_main/urls.pysiguiente manera:

    # jobs_board_main/urls.py
    from .views import get_jobs, get_job, subscribe
    
    urlpatterns = [
        # All jobs
        path('jobs/', get_jobs, name="jobs_view"),
        path('jobs/<int:id>', get_job, name="job_view"),
        path('jobs/<int:id>/subscribe', subscribe, name="subscribe_view"),
    ]
    

    Ahora podemos probar nuestra aplicaci贸n principal de Jobs Board al ver los listados de puestos de trabajo, hacer clic en uno y enviar una direcci贸n de correo electr贸nico que recibir谩 actualizaciones.

    Ahora que tenemos una aplicaci贸n en funcionamiento, es hora de incorporar Django Signals y notificar a los usuarios / suscriptores cuando se produzcan determinados eventos. Las ofertas de trabajo est谩n vinculadas a una determinada empresa cuyo correo electr贸nico registramos, queremos notificarles cuando un nuevo usuario se suscribe a su oferta de trabajo. Tambi茅n queremos notificar a los usuarios suscritos cuando se elimine una oferta de trabajo.

    Para notificar a los usuarios cuando una publicaci贸n de trabajo es eliminada o eliminada, utilizaremos la post_deletese帽al incorporada de Django . Tambi茅n crearemos nuestra se帽al llamada new_subscriberque usaremos para notificar a las empresas cuando los usuarios se suscriban a su oferta de trabajo.

    Creamos nuestras se帽ales personalizadas creando un signals.pyarchivo en nuestra jobs_board_mainaplicaci贸n:

    # jobs_board_main/signals.py
    from django.dispatch import Signal
    
    new_subscriber = Signal(providing_args=["job", "subscriber"])
    

    隆Eso es todo! Nuestra se帽al personalizada est谩 lista para ser invocada despu茅s de que un usuario se haya suscrito exitosamente a una publicaci贸n de trabajo de la siguiente manera en nuestro jobs_board_main/views.pyarchivo:

    # jobs_board_main/views.py
    
    # Existing imports and code are maintained and truncated for brevity
    from .signals import new_subscriber
    
    def subscribe(request, id):
        job = Job.objects.get(pk=id)
        subscriber = Subscriber(email=request.POST['email'])
        subscriber.save()
    
        subscription = Subscription(user=subscriber, job=job, email=subscriber.email)
        subscription.save()
    
        # Add this line that sends our custom signal
        new_subscriber.send(sender=subscription, job=job, subscriber=subscriber)
    
        payload = {
          'job': job,
          'email': request.POST['email']
        }
        return render(request, 'subscribed.html', {'payload': payload})
    

    No tenemos que preocuparnos por la pre_deletese帽al, ya que Django nos la enviar谩 autom谩ticamente justo antes de que se elimine una publicaci贸n de trabajo. La raz贸n por la que estamos usando pre_deletey no post_deletese帽al es porque, cuando Jobse elimina a, todas las suscripciones vinculadas tambi茅n se eliminan en el proceso y necesitamos esos datos antes de que tambi茅n se eliminen.

    Consumamos ahora las se帽ales que acabamos de enviar en una jobs_board_notificationsaplicaci贸n separada .

    Parte 2: La aplicaci贸n de notificaciones de Jobs Board

    Ya creamos la jobs_board_notificationsaplicaci贸n y la conectamos a nuestro proyecto Django. En esta secci贸n, consumiremos las se帽ales enviadas desde nuestra aplicaci贸n principal y enviaremos las notificaciones. Django tiene una funcionalidad incorporada para enviar correos electr贸nicos, pero para fines de desarrollo, imprimiremos los mensajes en la consola.

    Nuestra jobs_board_notificationsaplicaci贸n no necesita la interacci贸n del usuario, por lo tanto, no necesitamos crear vistas o plantillas para ese prop贸sito. Nuestro 煤nico objetivo es jobs_board_notificationsrecibir se帽ales y enviar notificaciones. Implementaremos esta funcionalidad en nuestro, models.pyya que se importa temprano cuando se inicia la aplicaci贸n.

    Recibamos nuestras se帽ales en nuestro jobs_board_notifications/models.py:

    # jobs_board_notifications/models.py.
    from django.db.models.signals import pre_delete
    from django.dispatch import receiver
    
    from jobs_board_main.signals import new_subscriber
    from jobs_board_main.models import Job, Subscriber, Subscription
    
    @receiver(new_subscriber, sender=Subscription)
    def handle_new_subscription(sender, **kwargs):
        subscriber = kwargs['subscriber']
        job = kwargs['job']
    
        message = """User {} has just subscribed to the Job {}.
        """.format(subscriber.email, job.title)
    
        print(message)
    
    @receiver(pre_delete, sender=Job)
    def handle_deleted_job_posting(**kwargs):
        job = kwargs['instance']
    
        # Find the subscribers list
        subscribers = Subscription.objects.filter(job=job)
    
        for subscriber in subscribers:
            message = """Dear {}, the job posting {} by {} has been taken down.
            """.format(subscriber.email, job.title, job.company)
    
            print(message)
    

    En nuestro jobs_board_notifications, importamos nuestra se帽al personalizada, la pre_savese帽al y nuestros modelos. Usando el @receiverdecorador, capturamos las se帽ales y los datos contextuales pasados 鈥嬧媍on ellos como argumentos de palabras clave.

    Al recibir los datos contextuales, los usamos para enviar los “correos electr贸nicos” (recuerde que solo estamos imprimiendo en la consola para simplificar) a los suscriptores y empresas cuando un usuario se suscribe y se elimina una publicaci贸n de trabajo respondiendo al se帽ales que enviamos.

    Pruebas

    Una vez que hayamos creado un trabajo en nuestro panel de administraci贸n, est谩 disponible para que los usuarios se suscriban. Cuando los usuarios se suscriben, se env铆a el siguiente correo electr贸nico desde la jobs_board_notificationsaplicaci贸n a la empresa propietaria de la publicaci贸n:

    Esta es una prueba de que nuestra new_subscriberse帽al fue enviada desde la jobs_board_mainaplicaci贸n y recibida por la jobs_board_notificationsaplicaci贸n.

    Cuando se elimina una publicaci贸n de trabajo, todos los usuarios que se suscribieron a la publicaci贸n de trabajo reciben una notificaci贸n por correo electr贸nico, de la siguiente manera:

    La pre_deletese帽al de Django fue 煤til y nuestro administrador envi贸 notificaciones a los usuarios suscritos de que se elimin贸 la publicaci贸n de trabajo en particular.

    Resumen

    En este art铆culo hemos construido un proyecto Django con dos aplicaciones que se comunican a trav茅s de Django Signals en respuesta a ciertos eventos. Nuestras dos aplicaciones est谩n desacopladas y la complejidad en la comunicaci贸n entre nuestras aplicaciones se ha reducido considerablemente. Cuando un usuario se suscribe a una oferta de trabajo, notificamos a la empresa. A su vez, cuando se elimina una publicaci贸n de trabajo, notificamos a todos los clientes suscritos que la publicaci贸n de trabajo se elimin贸.

    Sin embargo, hay algunas cosas que debemos tener en cuenta al utilizar Django Signals. Cuando las se帽ales no est谩n bien documentadas, los nuevos encargados de mantenimiento pueden tener dificultades para identificar la causa ra铆z de ciertos problemas o comportamientos inesperados. Por lo tanto, cuando se utilizan se帽ales en una aplicaci贸n, es una buena idea documentar las se帽ales utilizadas, d贸nde se reciben y la raz贸n detr谩s de ellas. Esto ayudar谩 a cualquiera que mantenga el c贸digo a comprender el comportamiento de la aplicaci贸n y a resolver problemas m谩s r谩pido y mejor. Adem谩s, es 煤til tener en cuenta que las se帽ales se env铆an sincr贸nicamente. No se ejecutan en segundo plano ni mediante trabajos asincr贸nicos.

    Con toda esta informaci贸n sobre las se帽ales de Django y el proyecto de demostraci贸n, deber铆amos poder aprovechar el poder de las se帽ales en nuestros proyectos web de Django.

    El c贸digo fuente de este proyecto est谩 disponible aqu铆 en Github .

     

    Etiquetas:

    Deja una respuesta

    Tu direcci贸n de correo electr贸nico no ser谩 publicada. Los campos obligatorios est谩n marcados con *