Para esta sesión se recomienda, hacer un nuevo clon en carpetas diferentes de los dos repositorios que hemos ido utilizando:
- https://github.com/AWS-User-Group-La-Paz/muyu-invoice-infrastructure
- https://github.com/AWS-User-Group-La-Paz/muyu-invoice-generator
Denle una leida a los README.md de cada repositorio para entender a más detalle la solución en general
En esta sesión vimos los beneficios y la importancia de desacoplar tareas de nuestra aplicación Muyu Invoices. Inicialmente vimos que la aplicación una vez se envie el form de generar una factura, lo hace todo dentro del mismo request lo cual puede ser problematico si este proceso llegase a ser muy pesado o la cantidad de usarios fuera demasiado, ese modelo simplemente no escalaría.
El objetivo de esta sesión fue la de mover esa tarea, como también el envío de emails a trabajo en segundo plano (un worker) y la comunicación entre nuestro backend y nuestro worker sería mediante el uso de colas, para este caso utilizando Amazon SQS (Simple Queue Service).
La nueva arquitectura se encuentra en el repositorio para que se analice
Partimos desde el punto de correr la aplicación localmente y emular un entorno de AWS localmente sin necesidad de utilizar nuestra cuento, lo cual es muy útil para entornos locales. Utilizamos el proyecto localstack para emular un entorno AWS en nuestras computadoras.
Posteriormente, vimos el concepto de staged deployment, ya para levantar la infraestructura local en terraform paso por paso. Vean el siguiente link del README.md para seguir los pasos.
Desde que comenzamos hasta ahora, la arquitectura de esta solución ha ido creciendo y ya tiene la forma de un proyecto real, es por eso que vale la pena darle una revisada al código terraform de la aplicación.
Al final de esta sesión el resultado final fue el de la arquitectura mencionada, un backend que envia el trabajo de generar las facturas a un worker mediante el uso de colas.