Laravel – Queues, workers, events, broadcast y commands
¿Cómo utilizar queues, workers, events, broadcast y commands en una tienda online?
Supongamos que tenemos una tienda. Al realizar una venta hay que generar la factura y enviársela al usuario y hacer la petición a logística, entre otras acciones. Todo eso tarda algo de tiempo y lo peor es que no sabemos cuánto va a tardar. Para empezar, la plataforma de emails no nos pertenece, no podemos estar seguros de que el email se ha mandado correctamente, tampoco podemos estar seguros de que en logística les haya llegado el aviso,…
Lo mejor es realizar estas acciones en segundo plano. Por ejemplo, en este caso, podemos enviar un evento de que una compra ha sido realizada. Este evento dispara un listener para generar la factura y otro para enviar un aviso a logística. Una vez llega a logística se envía otro evento dándonos luz verde y la factura, por su cuenta, se sigue generando. Una vez se genera manda su propio evento. Ahora sabemos que la compra se ha realizado, la factura se ha generado y en logística saben que es lo que hay que preparar. Entonces podemos enviar el email al usuario dándole el código de seguimiento que le han asignado y la factura que se ha generado.
Aquí hemos usado eventos y listeners para mandar información de un sitio para otro, una command para generar la factura y queues y workers para que todo funcionara en segundo plano.
También podríamos haber mostrado como mensaje después de la compra que se estaba generando todo esto y 5 segundos después, al recibir en evento de que el mail se ha enviado correctamente, mostrarle ese mensaje por pantalla. Para eso tenemos que hacer broadcast, así le aparece el mensaje sin necesidad de obligarle a recargar la página.
Al utilizar estas tecnologías el usuario acepta el pago, la aplicación le informa al instante de que todo va bien y se está generando lo necesario para enviarle la información del envío y la factura hasta que pocos segundos después le aparece otro mensaje informando de que todo ha salido como debía.
Nuestro código está dividido de forma muy lógica, una clase para generar la factura, otra para avisar a logística, otra para enviar el mail correspondiente, etc. Esto es mucho más fácil de mantener y al hacerlo de forma asíncrona hemos podido avisar a logística y preparar el pdf a la vez, así que la espera total (y la carga en el sistema) ha sido inferior.
Los eventos han ido al queue correspondiente. Los diferentes workers van realizando las acciones que hay a la espera en estos queues, uno de esos eventos en vez de ir a cola ha ido por broadcast al usuario y otro de los eventos ha disparado una command.
Todo esto tan complejo lo tenemos de serie al instalar Laravel, broadcast, eventos… Todo funciona bien y el desarrolador web es más feliz todavía que nuestro usuario.