Desenvolupament d'Aplicacions

Queues, workers, events, broadcast i commands a Laravel

Queues, workers, events, broadcast i commands ens faciliten moltes tasques en projectes web desenvolupats amb Laravel. Avui us mostrarem com.

Queues, workers, events, broadcast i commands a Laravel

Com utilitzar queues, workers, events, broadcast i commands a una botiga online?

Suposem que tenim una botiga online. Quan es realitza una venda cal generar la factura i enviar-la-hi a l'usuari i fer la petició a logística, entre altres accions. Tot això triga una mica de temps i el pitjor és que no sabem quant trigarà. Per començar, la plataforma d'emails no ens pertany, no podem estar segurs que l'email s'ha enviat correctament, tampoc podem estar segurs que a logística els hagi arribat l'avís,...

El millor és realitzar aquestes accions en segon pla. Per exemple, en aquest cas, podem enviar un esdeveniment que una compra ha estat realitzada. Aquest esdeveniment dispara un listener per generar la factura i un altre per enviar un avís a logística. Una vegada arriba a logística s'envia un altre esdeveniment donant-nos llum verda i la factura, pel seu compte, se segueix generant. Una vegada es genera mana el seu propi esdeveniment. Ara sabem que la compra s'ha realitzat, la factura s'ha generat i a logística saben que és el que cal preparar. Llavors podem enviar l'email a l'usuari donant-li el codi de seguiment que li han assignat i la factura que s'ha generat.

Aquí hem utilitzat esdeveniments i listeners per enviar informació d'un lloc per a un altre, una command per generar la factura i queues i workers perquè tot funcionés en segon pla.

També podríem haver mostrat com a missatge després de la compra que s'estava generant tot això i 5 segons després, en rebre en esdeveniment que el mail s'ha enviat correctament, mostrar-li aquest missatge per pantalla. Per a això hem de fer broadcast, així li apareix el missatge sense necessitat d'obligar-li a recarregar la pàgina.

Si utilitzem aquestes tecnologies l'usuari accepta el pagament, l'aplicació li informa a l'instant que tot va bé i s'està generant el necessari per enviar-li la informació de l'enviament i la factura fins que pocs segons després li apareix un altre missatge informant que tot ha sortit bé.

El nostre codi està dividit de forma molt lògica, una classe per generar la factura, una altra per avisar a logística, una altra per enviar el mail corresponent, etc. Això és molt més fàcil de mantenir i en fer-ho de forma asíncrona hem pogut avisar a logística i preparar el pdf alhora, així que l'espera total (i la càrrega en el sistema) ha estat inferior.

Els esdeveniments han anat al queue corresponent. Els diferents workers van realitzant les accions que hi ha a l'espera en aquests queues, un d'aquests esdeveniments en comptes d'anar a cua ha anat per broadcast a l'usuari i un altre dels esdeveniments ha disparat una command.

Tot això tan complex ho tenim de sèrie en instal·lar Laravel, broadcast des de fa pocs mesos, esdeveniments des de fa bastant més temps. Tot funciona bé i el desenvolupador web és més feliç que el nostre usuari.

Comparteix aquest article

Articles Relacionats