En este artículo os cuento una estrategia eficiente para desplegar una SPA con Azure Static Web Apps. Utilizando servicios como App Configuration y Azure Function Apps, esta propuesta os permite compilar la aplicación una vez y desplegarla en varios entornos sin necesidad de recompilación 😉
Dentro del ciclo de despliegue de una SPA, el escenario habitual para llevar nuestra aplicación a los diferentes entornos suele ser este:
Contamos con un número N de entornos y una configuración específica para cada entorno. En el proceso de despliegue de nuestra aplicación, realizamos un proceso de compilación o “build”, en el cual, adecuamos las configuraciones de la aplicación al entorno en el que deseamos desplegar el código.
Este enfoque tiene unos cuantos contras, como, por ejemplo, ¿qué pasa si en mi proceso de despliegue he configurado mal algún valor? estoy obligado a recompilar de nuevo toda mi aplicación para poder arreglar el error, o ¿por qué debería estar compilando más de una vez la misma versión de la aplicación? teniendo que compilar la aplicación por cada entorno estoy añadiendo tiempo de espera al proceso de entrega de valor y gastando tiempo de ejecución en la máquina que tiene que compilar mi código.
En este artículo veremos una manera de hacer que la configuración de nuestra aplicación sea proveída por el mismo entorno en el que estamos desplegando durante el arranque de la aplicación, de tal manera que solamente vamos a necesitar compilar una vez para poder desplegar donde queramos. Build once, deploy everywhere
Para alcanzar este escenario nos vamos a apoyar en unos cuantos servicios de Azure.
App Configuration
Es el servicio que nos va a servir como almacén de configuraciones. Aquí daremos de alta nuestras configuraciones, las etiquetaremos por entorno y será el lugar desde donde las consumamos.
Static Web Apps
Es el servicio en el que nos apoyaremos para realizar gran parte de la magia que vamos a necesitar. Ideal para desplegar nuestras aplicaciones de javascript.
De entre muchas de sus features, destaca que pone a nuestra disposición un proyecto de Azure Functions para invocar desde nuestra aplicación, como si fuese una especie de “back-end” al que podemos atacar a través del extremo “/api” desde el código de js.
El servicio de Static Web Apps cuenta con tiers:
- El tier Free, que establece las functions en modo “managed” y nos obliga a desarrollar el código dentro del mismo repositorio que el de la aplicación SPA.
- El tier Standart, que, costando 9 dólares al mes, además nos permite vincular cualquier proyecto de functions a nuestra web, sin necesidad de compartir repositorio o proceso de despliegue con el resto de la aplicación.
Functions Apps
Es el servicio que nos va a permitir ejecutar pequeñas lógicas en base a eventos, como, por ejemplo, llamadas HTTP, la subida de un archivo a un storage o una expresión cron.
Con las azure functions haremos la puerta de enlace entre nuestro App Configuration y nuestra Static Web App, permitiendo acceder al código de javascript a los valores de la configuración del entorno.
¿Qué vamos a necesitar?
Para conseguir el escenario deseado haremos uso de:
- Al menos un App Configuration
- Tantas Static Web Apps como entornos en los que deseemos desplegar nuestro código
- Tantas Azure Function Apps como Static Web Apps tengamos
Consideraciones de esta solución
A fecha de la escritura de este artículo, la posibilidad de conectar nuestras functions con App Configuration no está soportada por las functions de tipo “managed” lo cual nos obliga a establecer todas nuestras Static Web Apps en el plan Standart, y de esa manera poder vincular una Function App externa.
También, actualmente Static Web Apps solo permite enlazar un proyecto de functions a un único environment de la Static Web App, aún que quizás esto cambie en un futuro nos limita:
- El poder reutilizar el mismo proyecto de functions para todas nuestras Static Web Apps.
- La capacidad de levantar environment secundarios, ya que, si nuestra configuración es necesaria para el arranque de la aplicación, no tenemos acceso a ella desde otro environment que no sea el de Producción.
Hora de hacer la magia
Partimos del escenario en el que tenemos los recursos:
Un App Configuration
Un par de proyectos de functions
Para el ejemplo voy a partir de una aplicación de React generada con vite, en la que consultaremos con una llamada al inicio de la aplicación el valor de una configuración y se pintará por pantalla. Esta app esta subida a un repositorio de Github.
Toca crear unas Static Web Apps. Nos dirigimos al portal de azure e iniciamos el proceso de crear el recurso. En este punto es importante fijarnos en dos detalles.
- El tier del recurso. Nosotros lo necesitamos en la capa standart
- La ruta de la API. Como vamos a hacer uso de la capacidad de “bring you own function”, dejaremos ese campo vacío
Yo voy a enlazar el recurso con el repositorio de mi cuenta de GitHub para aprovechar que automáticamente se genera una Github Action que maneja el proceso de CI/CD de la aplicación.
Nuestra function
En la aplicación de React vamos a crear una nueva carpeta bajo “src” llamada api, en esta ruta es donde voy a dejar el código de mi function.
Al estar en el modelo de “bring you own function”, el código de nuestra function podría estar en cualquier lado, incluso en otro repositorio, nosotros nos encargamos de desarrollar, mantener y desplegar ese código por nuestra cuenta. El motivo por el que lo dejamos aquí es por comodidad.
Vamos a generar una function en NET 6 en modo Isolated. Para hacer esto nos podemos apoyar del scaffold que hace Visual Studio de un proyecto de functions.
Habiendo hecho todo esto nos quedará una estructura muy parecida a esta.
En el Program.cs del proyecto de functions vamos a configurar la conexión a nuestro App Configuration. Para ello vamos a necesitar los nugets:
- Azure.AppConfiguration.Functions.Worker
- Extensions.Configuration.AzureAppConfiguration
Y configuraremos el código de esta manera
En función de la variable de entorno en el que se despliegue nuestro código, consumiremos un conjunto de configuraciones u otro.
Si nos damos cuenta, estamos preparando la function para que sea sensible a reconocer los cambios en la configuración en tiempo de ejecución, escuchando el valor de “Sentinel”. En este otro artículo explico de forma detallada cómo funciona este mecanismo, así que te recomendó echarle un vistazo.
Ahora solo nos falta crear una function que consulte la configuración y la sirva como respuesta a una petición HTTP
Nuestra React App
Ahora, vamos a preparar nuestra app de React para llamar a nuestra function en el arranque y que obtenga la configuración.
Vamos a crear un fichero environment.ts, que nos servirá para almacenar la información de la configuración.
En el main.ts, vamos a hacer una llamada fetch al endpoint “/api/settings”. La ventaja de este modelo es que al ser nuestra function el “back-end” en la Static Web App, con invocar la ruta “/api” ya tenemos acceso a nuestras functions sin necesidad de conocer ninguna URL.
Y para hacer la prueba, voy a pintar un valor de la configuración en el componente principal de la aplicación que nos saluda con un amigable “Hello world!”.
En el portal de Azure
Para finalizar solo nos queda enlazar nuestra Static Web App con nuestra function, para que nos funcione como nuestro “back-end”.
Para hacer esto tenemos dos opciones, usar la interfaz del portal de azure o hacerlo mediante el Azure CLI. Yo personalmente recomiendo hacerlo mediante el CLI, ya que parece dar menos problemas. Se hace a través del comando
Y con esto, ya debería aparecer enlazado nuestro proyecto de functions a la Static Web App
A probar
Con todo el código desarrollado, la app de React junto al proyecto de functions desplegado y nuestros recursos vinculados ya podemos ver si todo esto funciona
Tenemos estos valores registrados en nuestro App Configuration, los cuales consumiremos en nuestras dos SPAs
Nos dirigimos a nuestra Static Web App para el entorno de DEV y vemos que tenemos un fantástico “Hello world from development!” que coincide con los valores de DEV de nuestra configuración.
Y ahora, si nos vamos a la Static Web App de PRO vemos que tenemos la misma página, pero con los valores correspondientes de ese entorno.
¡Lo hemos conseguido! ¡Nuestras SPAs están tomando la configuración del entorno en el que están desplegadas sin necesidad de ser compiladas cada vez!
Por último, veamos que pros y contras tiene esta aproximación
Pros y contras
PROS
- No tenemos que mantener la configuración de la aplicación en el código, las podemos tener en un repositorio común que está especializado en guardar ese tipo de información.
- No tenemos la necesidad de recompilar y desplegar cada vez que queramos cambiar la configuración, con modificar el App Configuration ya tenemos la aplicación lista casi al instante.
CONTRAS
- Al menos, hasta hoy día, perdemos la capacidad de levantar entornos secundarios en la Static Web App, ya que la configuración es necesaria para el arranque y no se puede tener vinculada la function a entornos secundarios.
Os dejo en este enlace el repositorio de GitHub con el código que he desarrollado para el artículo. Espero que lo hayas encontrado de utilidad.
¡Suscríbete a nuestras RRSS!
