Has construido una aplicación y quieres que escale. ¿Quieres CI/CD, dominios personalizados, certificados SSL, APIs, escala global de tus activos estáticos, autenticación y autorización? Aprendamos cómo construir una aplicación web estática en Azure y pasar de un repositorio de GitHub a escala global en minutos.
¡De código a escala! Construye una aplicación web estática en minutos
Video Summary and Transcription
La charla discute el desarrollo de aplicaciones web y los desafíos involucrados, como la gestión de código, CI/CD, enrutamiento, seguridad y escalabilidad. Explora el uso de Azure Static Web Apps para construir e implementar aplicaciones web estáticas con características como autorización, autenticación y tecnología sin servidor. Se demuestra el proceso de creación de una aplicación web estática en Azure Portal, junto con la creación de recursos, implementación y configuración de dominio personalizado. La charla también cubre la implementación de API, autenticación, autorización y control de acceso basado en roles. Azure Static Web Apps se destaca como una solución distribuida a nivel mundial para construir aplicaciones web.
1. Introducción al desarrollo de aplicaciones web
Has construido una aplicación que conecta a las personas que necesitan comestibles con aquellos que pueden proporcionarlos. Después de desarrollar tu aplicación, debes considerar la gestión de código, CI/CD, APIs, enrutamiento, seguridad, autenticación, autorización y escalabilidad global. Hay más de 30 frameworks disponibles para construir aplicaciones web, lo cual ha cambiado fundamentalmente el proceso de desarrollo. Ahora construimos aplicaciones del lado del cliente que se ejecutan completamente en el navegador, lo que requiere un nuevo tipo de aplicación para manejar este cambio.
Gracias a todos por recibirme aquí en JS Nation y a todos los organizadores por organizar esto hoy. Quiero comenzar con una pequeña historia para ustedes. Has construido una aplicación, eres un desarrollador, esto es lo que haces y tu aplicación conecta a las personas que necesitan obtener comestibles con aquellas personas que pueden proporcionarlos. Ahora millones de personas podrían usar esto hoy en el mundo, así que pensemos en lo que necesitarías después de desarrollar tu aplicación. Por supuesto, necesitas tu código y probablemente lo almacenas en un lugar como GitHub y quieres subirlo a GitHub para asegurarte de que tu código esté disponible y sea de código abierto pero también quieres CI CD. ¿Tienes esto para asegurarte de que lo estás testing y construyendo y luego lanzando nuevas versiones? ¿Qué hay de tus API? ¿Estás configurado para tener API y funciones serverless o un servicio backend o cómo se coordina todo eso? Y luego debes asegurarte de que tienes configurado el enrutamiento correctamente. Entonces tienes tu aplicación, tienes tus API, ¿se comunican bien entre sí? ¿Necesitas configurar cores? ¿Qué hay de un proxy inverso? Ahora llegamos a cosas como seguridad. ¿Tienes certificados SSL en un dominio personalizado? Por supuesto, quieres tu propio dominio para tu sitio web público. ¿Cómo estableces esto y qué hay de la autenticación? Quieres asegurarte de saber quiénes son las personas que inician sesión en su aplicación para asegurarte de que estén autenticados y, por supuesto, la autorización para asegurarte de que los roles que proporcionan en tu aplicación ya estén establecidos. ¿Y qué hay de la escala global? Puedes estar en Europa, Asia, Estados Unidos o Sudamérica, puedes estar en cualquier lugar y tus usuarios también pueden estar en cualquier lugar. ¿Tu aplicación se escala en todo el mundo? ¡Vaya, solo querías construir una aplicación, ¿verdad? Solo tenías tu código y bueno, ¿con qué construiste tu código con? ¿Usaste algo como Angular o tal vez usaste react o posiblemente algo más nuevo como Svelte o tal vez eres desarrollador de Vue o algo completamente diferente? Hay más de 30 frameworks diferentes que podrías estar usando hoy y estoy seguro de que ese número es aún mayor. Entonces, las herramientas de hoy han cambiado fundamentalmente cómo construimos aplicaciones web. Ya no tenemos un runtime de servidor que tenemos que producir nuestros sitios web y constantemente hacer estas actualizaciones de página. Ahora estamos construyendo aplicaciones basadas en el lado del cliente o aplicaciones web estáticas que usamos y las aplicaciones se construyen y luego se ejecutan completamente en el navegador. Entonces hemos trasladado estas responsabilidades de la aplicación desde el servidor completamente al cliente y necesitamos un nuevo tipo de aplicación para manejar esto. Así es como funciona el proceso, donde tenemos un NPM run build o cualquier comando que puedas tener y todo tu código debe ser construido antes de
2. Construcción e implementación de aplicaciones web estáticas
El proceso de construcción genera activos estáticos como HTML, JavaScript y CSS. Los servidores web tradicionales no pueden manejar los pasos de construcción, por lo que se necesita un nuevo tipo de servicio en la nube como Azure Static Web Apps. Con Azure Static Web Apps, puedes construir y alojar tus aplicaciones web, manejar la autorización y autenticación, utilizar tecnología serverless con Azure Functions e implementar la integración y implementación continua. Detrás de escena, tu código se envía a un repositorio de GitHub, lo que desencadena una acción de GitHub que construye e implementa el contenido estático y las APIs. El resultado es una aplicación web estática implementada globalmente. Vamos a realizar una demostración donde crearemos una aplicación, la conectaremos a una API y cubriremos la autorización y autenticación.
3. Creación de una aplicación web estática en Azure Portal
Voy a Azure Portal, hago clic en Static Web Apps Preview y agrego una nueva aplicación. Tengo una suscripción de Azure y puedo crear un grupo de recursos. Lo llamaré John Papa, SWA-JSNation, SWA para Static Web Apps. Elegiré el mismo nombre para mi aplicación y seleccionaré la región Este de EE. UU. Iniciaré sesión con GitHub y elegiré mi organización y repositorio. Luego conectaré la rama principal. A continuación, haré clic en build y especificaré la ubicación de la aplicación, la carpeta de APIs y la ubicación del artefacto. Después de completar los detalles, revisaré y crearé, luego presionaré el botón de creación para implementar los recursos.
4. Explorando la Creación y Implementación de Recursos
Una vez que se crean los recursos, vamos a echar un vistazo a las cosas conectadas. En el historial de implementación, podemos ver la construcción de la aplicación en GitHub actions. Dentro del archivo de flujo de trabajo, tenemos los detalles que completamos en el portal. La aplicación Svelte está en la carpeta de código fuente, y la carpeta pública es donde se implementarán los activos compilados. Sin embargo, no hay una carpeta de funciones.
5. Construcción e Implementación de la Aplicación Web
Cometí un error tipográfico en la carpeta de la API, pero la compilación se completó correctamente. Verás los pasos del proceso de compilación, incluyendo NPM install y NPM run build. En la parte superior, hay un mensaje sobre no encontrar el directorio de la API, pero aún se realizará la compilación. Podemos hacer clic en el enlace para acceder a la aplicación implementada. Por defecto, tenemos HTTPS, pero si queremos un dominio personalizado, necesitamos configurar DNS.
6. Configuración de Dominio Personalizado y Conexión de la API
Puedes configurar un dominio personalizado comprándolo, configurando el CNAME en tu DNS y validándolo en Azure. Sin embargo, los sitios estáticos con rutas del lado del cliente pueden encontrar problemas al actualizar la página. Para solucionarlo, elimina la ruta del lado del cliente y realiza los ajustes necesarios en la aplicación. Hemos creado la aplicación, agregado escalado global, SSL, dominios personalizados y comenzado a configurar la API. Ahora, conectemos la API, solucionemos la ruta de fallback y creemos una solicitud de extracción para un sitio secundario o de vista previa.
Y puedes ver esto conmigo. Está en shopathome.dev. Así que este sitio web está en funcionamiento. Es mi dominio. Y en Shop At Home, podemos hacer clic en este icono, y podemos ver que hay un certificado y que es válido. Podemos ver ese certificado aquí mismo. Entonces, ¿qué se necesita para configurar un dominio personalizado? Bueno, si volvemos al portal, notarás, en el lado izquierdo, la pestaña de dominios personalizados que nos permite hacer clic en agregar. Luego podemos ver, en la parte superior, que el primer paso es una vez que compras un dominio personalizado, simplemente configuras el CNAME dentro de tu DNS y te dice exactamente qué ingresar. Luego escribes tu dominio personalizado aquí en el cuadro, lo validas. Aquí es donde Azure se asegurará de que lo poseas y tengas los permisos para ello. Y luego haces clic en el botón de agregar en la parte inferior. Y una vez que se haya hecho eso, verás algo como en la solución final, aquí está nuestro dominio personalizado y está shopathome. Así es como funciona eso. Entonces, podríamos conectar SSL y un dominio personalizado, pero una cosa de la que debemos ser conscientes es que los sitios estáticos que tienen rutas del lado del cliente, esas rutas del lado del cliente no se asignan a nada en el servidor. ¿Qué significa eso? Eso significa que aquí arriba, nota que tengo /home como mi ruta principal. No hay home.html en esta aplicación en particular porque no usé el renderizado del lado del servidor. Si lo hiciera, estaría bien, pero como no lo hice, mira lo que sucede cuando actualizo la página. 404. No es realmente un 404, ¿verdad? Porque hay una ruta del lado del cliente que se asigna a eso, pero necesito volver a ingresar a la aplicación y solucionar esto, y hay una forma de hacerlo con aplicaciones web estáticas. Entonces volvamos, eliminemos el home y podemos ver nuestra aplicación. ¿Dónde lo dejamos? Construimos tu aplicación y agregamos todas estas cosas aquí. Agregamos nuestro escalado global. Tenemos una aplicación que se encuentra en múltiples ubicaciones alrededor del mundo, cerca de tus clientes. Hablamos sobre SSL y cómo obtener dominios personalizados. Comenzamos a configurar nuestra API, que estamos a punto de hacer ahora mismo, y también configuramos nuestras solicitudes de extracción de GitHub. Así que veamos cómo podemos conectar la API, solucionar nuestra ruta de fallback y creemos una solicitud de extracción para que no afectemos el sitio de producción, sino que configuremos un sitio secundario o una vista previa. Vamos a volver a nuestra aplicación. Necesitamos obtener nuestro código localmente para poder ver qué está sucediendo. Aquí ya tengo el código clonado y voy a ejecutar git pull. ¿Por qué git pull? Porque el archivo de flujo de trabajo se agregó al repositorio por mí.
7. Changing API Location and Setting Fallback Route
Ahora podemos cambiar la ubicación de la API de funciones a API en el archivo de flujo de trabajo. También configuramos una ruta de fallback en el archivo routes.json para manejar errores 404. Después de hacer commit y push a los cambios, creamos una solicitud de extracción y comenzamos el proceso de compilación e implementación. La solución final incluye una ruta de fallback que carga correctamente la aplicación del lado del cliente basada en el enrutador Svelte.
Ahora los archivos de flujo de trabajo están en GitHub workflows. Ahora podemos verlo aquí mismo y lo primero que debo recordar es que quiero cambiar esa línea 31 de la ubicación de la API de funciones a API. Pero antes de hacer eso, recuerda que no quiero cambiar el sitio de producción. Quiero hacer esto en el sitio de vista previa. Así que usemos los comandos de VS Code para cambiar a una nueva rama y la llamaremos mi API. Ahora que estoy en una nueva rama, puedo cambiar funciones por API aquí mismo y guardaremos ese archivo. Y ahora también quiero configurar el fallback. Así que la ruta de fallback porque todo va a la carpeta public, esa es la implementación. Voy a crear un nuevo archivo llamado routes.json y en routes.json quiero decirle que si obtienes un 404, es posible que no sea realmente un 404. Carga la aplicación del lado del cliente porque el enrutador Svelte puede decirte que en realidad es la página de inicio. Para hacer eso, puedo configurar una ruta de fallback usando un fragmento de código. Aquí estoy diciendo que vaya y cargue la página de índice si es necesario. Ahora voy a hacer commit de estos cambios. Lo llamaré fallback y API y luego haré push de esos cambios. Y me preguntará si quiero hacer push al upstream. Diré que sí. Así de simple. Y luego podemos volver a nuestro repositorio de GitHub aquí mismo, a la pestaña de solicitudes de extracción. Y deberíamos ver que tenemos la oportunidad de comparar una solicitud de extracción para la API y voy a seguir adelante y crear la solicitud de extracción. Y una vez que hagas eso, lo que sucede es que verifica. Mira, hay un conflicto con la rama. Y en un momento, te mostrará un mensaje que iniciará el flujo de trabajo que ya creamos. Y podemos ver eso aquí mismo. Podemos hacer clic en los detalles del paso de compilación e implementación. Ahora podemos ver que este archivo de flujo de trabajo se está reconstruyendo para la solicitud de extracción. El sitio principal sigue en funcionamiento, pero ahora tenemos un sitio de solicitud de extracción. Así que en lugar de esperar esto, porque lleva alrededor de un minuto y medio, veamos la solución final. En la solución final, deberíamos tener una ruta de fallback. Así que aquí estoy en la página de productos. Si hago clic en actualizar, notarás que va directamente a la página de productos nuevamente. Estoy en inicio y hago clic en actualizar, va directamente a inicio.
8. Explorando la Implementación de la API y la Autenticación
El fallback funciona y la API está implementada. Una solicitud de extracción permite cambiar a Vue, creando un sitio secundario. La autenticación y autorización son aspectos importantes a considerar.
Entonces, el fallback funciona. Y también notarás que cuando haces clic en la lista, obtenemos nuestros data. Eso se debe a que nuestra API ahora está implementada porque le dijimos que vaya a la carpeta correcta. Así que todo eso está conectado y todo está funcionando. Pero vayamos a ver el sitio de producción y veamos que tengo una solicitud de extracción aquí. Y digamos que quiero cambiar de Svelte a Vue en lugar de una solicitud de extracción, solo porque soy un poco loco así. En esta solicitud de extracción, eso es lo que hice. Y configuró una nueva URL. Una vez que la solicitud de extracción se ha construido e implementado, en realidad te proporciona el enlace a esa URL secundaria o de vista previa aquí mismo. Así que puedo hacer clic en eso. Ahora puedes ver que este es mi sitio secundario que se está ejecutando y es de un color diferente porque es Vue. Así que puedo ver qué está sucediendo allí. Ahora tengo mi sitio principal de producción y tengo mi URL de vista previa lista para usar. Así que hemos hecho bastante con la aplicación y la API. Configuramos todo esto para crear nuestra aplicación y configurar nuestras rutas que necesitamos. Pero, ¿qué pasa con la autenticación y autorización? Aquí es donde las cosas pueden complicarse un poco. Entonces
9. Setting Up Authorization and User Roles
Para configurar la autorización, ve al archivo routes.json y especifica el proveedor de autenticación. Puedes bloquear proveedores específicos para reducir las opciones. Además, puedes configurar rutas con restricciones basadas en roles de usuario. Los usuarios autenticados pueden acceder a ciertos datos, pero la edición está limitada a usuarios preferidos. Haz commit y push de los cambios para completar la configuración.
10. Authentication and Role-based Access Control
Vamos a ver la aplicación en funcionamiento y ver cómo funciona esto. Podemos navegar por las diferentes rutas y ver cómo se implementa la autenticación y el control de acceso basado en roles. Al iniciar sesión con diferentes proveedores, como Twitter o GitHub, podemos probar el acceso a diferentes partes de la aplicación. La función de gestión de roles nos permite asignar roles a los usuarios y controlar su acceso a contenido específico. Invitar a nuevos usuarios y generar enlaces de invitación es un proceso sencillo.
11. Introducción a Azure Static Web Apps
Azure Static Web Apps ofrece una solución fácil de usar para construir aplicaciones web con un flujo de trabajo unificado, APIs sin servidor y autenticación y autorización integradas. Acaba de ser lanzado el 19 de mayo y ofrece una amplia documentación y tutoriales para varios frameworks como Angular, React, Gatsby, Hugo y VuePress. Puedes construir tu aplicación y lograr una escalabilidad global.
QnA
Gratitude, Frameworks, and Global Distribution
Quiero agradecerles por venir hoy y agradezco a todos los de JS Nation por su apoyo. El marco de trabajo funciona con prácticamente cualquier cosa que uses hoy en día con JavaScript, incluso cosas como Jekyll. Funcionará con contenido web del lado del servidor y marcos de trabajo del lado del cliente como Angular, React y más. La solución está distribuida a nivel mundial, lo que te permite acceder a ella desde cualquier parte del mundo. Y no, no significa que puedas recibir una pizza entregada en tu casa.
Aparecí. El aparecedor de John ha aparecido. El aparecedor apareció. Bueno saberlo. Ok, entonces, um, una de las preguntas que sé que todos te van a hacer es, ¿con qué marcos de trabajo funciona todo esto? El marco de trabajo, funcionará con prácticamente cualquier cosa que uses hoy en día con JavaScript, incluso cosas como Jekyll. Así que te gusta Jekyll. Puedes usarlo para alojar estas aplicaciones. Cualquier cosa que cree contenido web del lado del servidor, cosas como Nuxt y Next, Gatsby, Hugo. Funcionará con cosas del lado del cliente, por lo que puedes hacer, ya sabes, Angular, React, Fused, Felt, Marco, LitHTML. De hecho, tengo un repositorio que creé llamado John Poppa, Hello-worlds en GitHub. Y si lo miras, hay 31... creo que son 31, 31 tipos diferentes de marcos de trabajo. Y los uso para probar qué puedo cargar en ellos. No sabía que había 31 tipos diferentes de marcos de trabajo, pero... Hay algunos que nunca había oído hablar hasta hace poco. Sí. Supongo que no los he contado, los marcos de trabajo desde el último martes. Sin duda, otros 10 han sido inventados desde entonces. Ahí está tu error. Hombre, el conteo de marcos de trabajo debería hacerse a diario si quieres tener un proyecto adecuado. Así que gracias por... gracias por contar los marcos de trabajo. Dices que está distribuido a nivel mundial, ¿qué significa eso en realidad? Eso significa que puedes recibir una pizza entregada en tu casa en cualquier momento, en cualquier lugar del mundo por... Espera, no. Ese es el otro Papa John.
Global Distribution and Authentication
Azure Static Web Apps coloca el contenido lo más cerca posible de los usuarios, sin ningún esfuerzo adicional. Sirve el contenido y permite vincularlo a una API para operaciones con estado. Los roles de usuario especiales actualmente requieren una invitación manual, pero hay un problema abierto para explorar otras opciones. La integración con GitHub Pages es posible, pero esta solución ofrece características más personalizadas. Ampliar el sistema de autenticación más allá de las opciones enumeradas es un problema abierto en GitHub.
Eso significa que hay servidores en todo el mundo que son puntos de presencia en diferentes continentes y países, y estamos ajustando constantemente eso también. En este momento, Static Web Apps está en vista previa, que es como una versión alfa o beta. Así que lo estamos probando para ver, ¿los lugares donde hemos distribuido en todo el mundo son los lugares que la mayoría de las personas están usando? Así que imagino que esas cosas podrían cambiar, pero básicamente coloca el contenido lo más cerca posible de tus usuarios, y no tienes que hacer nada para que suceda. Genial. Pregunta de Beresford. ¿Los servidores de activos estáticos mantienen sesiones o estados de sesión? ¿Podría ser mediado por un tercero, pero eliminar ese cálculo facilitaría llegar al trío de 10K? ¿Cuál fue la última parte de esa pregunta, lo siento? ¿El qué trío? ¿Podría esto ser mediado por un tercero? Podrías usar... No estoy seguro de entender completamente la pregunta, pero creo que si estás hablando de estado de sesión en general, esto solo sirve el contenido. Entonces, si quieres que tenga algo de estado, mi solución ideal sería vincularlo a una API que ofrezca estado. Podrías usar funciones serverless para hacer eso, o simplemente podrías apuntar a cualquier API de tu elección para gestionar ese estado entre las aplicaciones. Es solo una aplicación web normal, por lo que podrías rastrear quién es el usuario y luego usar eso dentro de algún tipo de almacenamiento, como un almacenamiento de Reddit, incluso si quisieras. Genial. Beresford, si tienes un boleto pagado, puedes ir a la sala de Zoom después y preguntarle a John Moore sobre eso, si no respondí completamente la pregunta. No estoy seguro de haberlo formulado de manera especialmente precisa. Drum preguntó, ¿hay alguna forma de automatizar los roles de usuario, por ejemplo, agregar un rol a un usuario después del pago? ¿Ofrece Azure algunas soluciones de GraphQL y base de datos? Esa es una excelente pregunta. Hasta el día de hoy, en vista previa, la única forma de tener usuarios es que todos los que usen Twitter, Facebook, GitHub, cualquier técnica de autorización que necesites, automáticamente obtengan el anonimato, se registren y se autentiquen como un rol. Si quieres roles especiales, debes invitarlos desde el portal de Azure hoy. Hay un problema abierto en GitHub sobre esto, en nuestro sitio web, y creo que es github.com slash Azure slash static dash web dash apps. Y también puedo publicarlo en Twitter. Y hay un problema abierto sobre esto donde se está hablando sobre este tema exacto de tener otras formas para que las personas se registren en roles, se creen automáticamente en roles, etc. Así que por favor, agrega tus comentarios allí. Porque ahora es el momento de hacer que el equipo de ingeniería escuche los comentarios, ya que todavía estamos articulando lo que estará en el producto final. Increíble, y Didem, Didem, Didem, ¿ves un futuro en el que esto se integre con las páginas de GitHub? No puedo hablar en nombre de GitHub sobre esto y hacia dónde se dirigen con las páginas de GitHub. Ya sabes, como cualquier empresa grande, tenemos muchos productos que tienen cierta superposición de diferentes formas. La propia página de GitHub alojará una aplicación, ¿verdad? Pero si quieres, y si solo quieres alojar una aplicación, hay muchas opciones. Pero si quieres todas las cosas que mostré en la presentación aquí, con seguridad y distribución global y SSL y dominios personalizados, y todo funciona de manera sencilla, esta es una solución más adaptada para eso, en lugar de levantar una sola página, por ejemplo. Entonces, ¿estas cosas podrían superponerse? Absolutamente. Todas las grandes empresas tienen muchos productos que se superponen, desafortunadamente. Afortunadamente, quiero decir, muchas cosas, muchas cosas pueden superponerse, pero el producto real está dirigido a personas muy diferentes, tal vez. Databite pregunta, ¿puedes ampliar el sistema de autenticación para permitir más de los cinco enumerados aquí? Por ejemplo, ¿configurar SAML para SSO con otras organizaciones que podrían estar utilizando una lógica u Okta? Esa es otra excelente pregunta. Y también es uno de los problemas abiertos en
Addressing Questions and Feedback
Ha habido preguntas sobre Okta, Auth0 y SAML. Por favor, proporciona tus comentarios en los problemas de GitHub. El equipo está revisando activamente los comentarios. Gracias por tu aporte.