¡De código a escala! Construye una aplicación web estática en minutos

Rate this content
Bookmark

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.

31 min
18 Jun, 2021

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.

Available in English

1. Introducción al desarrollo de aplicaciones web

Short description:

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

Short description:

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.

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 que requieren las aplicaciones, solo sirven el código. Necesitamos un nuevo tipo de servicio en la nube, como Azure Static Web Apps, para manejar esto y aquí es donde herramientas como Azure Static Web Apps realmente pueden ayudarte. Gracias por venir hoy, mi nombre es John Papa y te mostraré cómo puedes construir e implementar una aplicación web estática en solo minutos. Así que hablemos sobre qué son las aplicaciones web estáticas y cómo Azure Static Web Apps te ayuda a lograrlo. En este proceso, vas a construir y alojar tus aplicaciones web. Quieres construirlas y alojarlas, esa es la parte clave. Es posible que también desees autorización y autenticación, saber quiénes son los usuarios y qué pueden hacer. También es posible que desees tener APIs. La mayoría de las aplicaciones tienen datos en algún lugar, por lo que vamos a utilizar tecnología serverless, en este caso, utilizando Azure Functions. También quieres tener CI/CD, integración continua para construir y probar tus aplicaciones de manera constante, y implementación continua para implementar tus aplicaciones en producción o tal vez en una URL de vista previa para no interrumpir tu sitio de producción cuando quieras ver qué está sucediendo. Ahora, echemos un vistazo a lo que realmente está sucediendo detrás de escena. Aquí tenemos un repositorio de GitHub. Todo nuestro código podría estar en él, y decidí que mi código está en una carpeta de la aplicación, y mi tecnología serverless está en una carpeta de API. Puedes poner el tuyo donde desees, y luego subimos nuestro código a GitHub y tal vez hacemos una solicitud de extracción a una rama, y esto dispara una acción de GitHub, un archivo de flujo de trabajo que luego ejecuta nuestros comandos. ¿Qué hace eso? Ejecuta npm run build y luego implementa el contenido estático, es decir, HTML, JavaScript y CSS, en un sitio web, y si los tenemos, nuestras APIs con Azure Functions, que son opcionales en este proceso. Luego, colectivamente, esas dos cosas se convierten en nuestra aplicación web estática y se implementan globalmente en todo el mundo con múltiples puntos de presencia. Eso es lo que está sucediendo detrás de escena. Ahora es el momento de ver qué está sucediendo y probarlo nosotros mismos. Así que vamos a realizar una demostración, pero antes de hacerlo, veamos qué vamos a hacer. Vamos a crear una aplicación y la vamos a conectar a una API. Así que tenemos nuestros datos con la aplicación. Y luego vamos a cubrir la autorización y autenticación. Comencemos donde comienzas, y eso es con tu código en GitHub. Pasemos a nuestra aplicación. Aquí tenemos un repositorio de GitHub que también puedes revisar. El mío se llama jsnationlive2020. Y lo que quiero hacer es tomar esta aplicación, que puedes ver que tengo Angular, React, Svelte y Vue aquí. Normalmente no ejecutaría los cuatro, pero hoy elegiré Svelte, ¿por qué no? Esta aplicación está escrita en cuatro tecnologías diferentes, para que puedas probarla tú mismo.

3. Creación de una aplicación web estática en Azure Portal

Short description:

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.

Y voy a ejecutar esa aplicación. Así que voy a ir a Azure Portal y voy a hacer clic en Static Web Apps Preview. Actualmente está en vista previa. Y aquí, lo que puedo hacer es hacer clic en Agregar. Y luego, después de hacer clic en Agregar, me llevará a un asistente donde puedo completar algunos pasos aquí. Primero, tengo una suscripción para Azure, que puedes obtener una prueba gratuita, y te mostraré un enlace para eso más adelante en las demostraciones. Y puedo crear un grupo de recursos. Los grupos de recursos son como un nombre, es como una carpeta para poner cosas. Así que lo llamaré John Papa, SWA-JSNation, SWA para Static Web Apps. Y luego le daré un nombre a mi aplicación. Así que podemos llamarla igual por ahora. Eso está bien. Y luego seleccionaremos nuestra región. Yo estoy en la región Este de EE. UU., así que la seleccionaré. Iniciaré sesión con GitHub para poder conectarme directamente a mi repositorio. Elegiré mi organización y luego elegiré mi repositorio, que se llamaba JS Nation Live 2020. Así que escribiré un poco aquí para filtrarlo. Y luego elegiré la rama que quiero implementar. Así que ahora voy a conectar la rama principal. El siguiente paso, voy a hacer clic en build. Esto es importante porque aunque hay valores predeterminados, la estructura de la aplicación de cada persona es un poco diferente. Entonces, la ubicación de la aplicación, ¿dónde se encuentra tu código? El mío está en una carpeta de aplicación Svelte. Mis APIs. Digamos que pongo mis APIs dentro de una carpeta llamada functions. Y luego el artefacto. Aquí es donde se encuentra la ubicación de tu compilación. ¿Dónde va a poner Svelte sus activos compilados, tu HTML, JavaScript y CSS? Para Svelte, sucede que es public. Así que completo estos datos y luego hago clic en revisar y crear. Luego me mostrará una pantalla de revisión y luego volveré a presionar el botón de creación. Y ahora está

4. Explorando la Creación y Implementación de Recursos

Short description:

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.

Desplegando algunos de estos recursos. Y una vez que se crean los recursos, me dará un botón azul que dice ir a ver esos recursos, lo cual haremos en un momento. Y luego, vamos a echar un vistazo a las cosas a las que está conectado. Aquí está el recurso al que podemos ir. Ahora, en la esquina superior derecha, podemos ver un par de cosas. La URL. Yellow plant. Ahí es donde está nuestra aplicación web. Haremos clic en eso brevemente, y nos mostrará que todavía está construyendo la aplicación, que acabamos de iniciar. Así que cerraré esa ventana. El historial de implementación. Aquí es donde se está construyendo la aplicación dentro de GitHub actions. Vamos a echar un vistazo a eso ahora. Así que vamos al repositorio, y podemos ver que estamos en la pestaña de acciones, y puedes ver aquí abajo, hay un punto amarillo junto a la acción en ejecución. Amarillo significa que está en progreso. Si hacemos clic en esto, podemos seleccionar el archivo de flujo de trabajo porque todavía se está construyendo. Veamos qué construyó en realidad para nosotros. Dentro del archivo de flujo de trabajo, hay muchas cosas aquí que dicen, `oye, cuando toques la rama principal, incluso con solicitudes de extracción, reconstruye esta acción`. Y en este primer trabajo, notarás aquí abajo en la línea 30, esto es lo que completamos en el portal. Así que puedes cambiar esto más tarde si cometiste un error tipográfico. Ubicación de la aplicación, aplicación Svelte, ubicación de la API, eso es meras funciones, ¿y dónde está el código de los activos compilados? Eso es lo que vamos a implementar. Eso está en la carpeta pública. Así que aquí podemos ver eso. Podemos volver al repositorio mismo y ver esas carpetas. Así que podemos ver aquí que la aplicación Svelte está justo ahí. Ahí es donde está nuestro código fuente. Sabemos que la carpeta pública es donde se va a implementar.

5. Construcción e Implementación de la Aplicación Web

Short description:

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.

Carpeta de funciones. Cometí un error tipográfico. En realidad, es una carpeta de la API. Pero está bien. Eso fue a propósito. Vamos a echar un vistazo y ver qué sucede cuando cometemos un error tipográfico. Ahora puedes ver que realmente se compiló. Y aquí está con la marca de verificación verde. Vamos a volver. Haremos clic en construir e implementar a la izquierda. Y podemos ver que todos los pasos están en verde. En la construcción e implementación, podemos abrir los pasos. Y nos muestra todo lo que ha sucedido. Verás cosas como NPM install ejecutándose aquí. Y NPM run build justo aquí en la línea 88. Y luego, en la parte inferior, verás que puedes ver tu sitio en yellow plant en esta URL, por eso los dominios personalizados son tan agradables. Podemos configurar eso. Y podemos copiar esto e ir a él. Pero en la parte superior, también verás un mensaje sobre que no se pudo encontrar el directorio de la API aquí en la línea 13. Eso es porque yo cometí un error tipográfico, no tú. Y eso está bien, porque de todos modos se va a compilar. Así que una opción es hacer clic en el enlace aquí. También puedo volver al portal y luego hacer clic en el enlace justo allí. Y aquí está la aplicación que acabamos de implementar en la nube. Entonces, ¿qué obtuvimos? Bueno, tenemos nuestra aplicación aquí. Eso es genial. Pero, ¿qué pasa con la seguridad? Hablamos de SSL. Observa, aquí arriba, tenemos HTTPS, por defecto, justo ahí. Bueno, eso no es un dominio personalizado, sin embargo. Entonces, ¿qué pasa si queremos un dominio personalizado? Porque eso lleva un minuto configurarlo debido a que tenemos que configurar DNS. Veamos una solución final.

6. Configuración de Dominio Personalizado y Conexión de la API

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

vamos a echar un vistazo a lo que hacen por nosotros. Ahora, en nuestra aplicación, queremos asegurarnos de poder configurar la autorización. Una de las formas de hacer eso es volver a este archivo routes.json. Siempre quiero que la ruta de fallback sea la última, porque eso solo debería ocurrir si todo lo demás falla. Sabes que recorremos las rutas una a la vez. Bueno, lo que quiero es asegurarme de tener un proveedor de autenticación. Y Azure Static Web Apps admite cinco proveedores de autenticación: Twitter, GitHub, Azure Active Directory, Google y Facebook. Pero ¿qué pasa si no quiero admitirlos a todos? En realidad, puedo poner bloqueadores en esta ruta para decir que no admita Facebook y no admita Google, porque tal vez cinco formas de autenticación sean demasiadas. No es nada en contra de ellos, simplemente tenemos que reducir el campo. Eso le dirá que no se autentique con ellos, pero permita Twitter, Azure Active Directory y GitHub. Y ahora, ¿qué pasa si también queremos asegurarnos de que los usuarios autenticados puedan ver los datos, pero no pueden editar los datos? También podemos configurar rutas con restricciones como esta, aquí estoy diciendo que solo puedes ir a los descuentos si eres un usuario preferido. Ese es un rol que vamos a crear, usuarios preferidos. También solo puedes editar eso es lo que significa la X. Tengo rutas bajo X que son de edición o si eres preferido. Pero cualquier usuario autenticado puede acceder a otros datos como la lista de productos. Ahora solo tengo que hacer commit y push con nuestro PR para

10. Authentication and Role-based Access Control

Short description:

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.

haz push. Vamos a ver la aplicación en funcionamiento y ver cómo funciona esto. Así que en esta aplicación en este momento está en shop at home. Observa que estoy conectado. Voy a cerrar sesión y mostrarte cómo funcionan estas rutas para nosotros. Primero, dentro de esto, puedo ir a la página de inicio, pero no puedo ver la lista de data. No estoy autenticado, por lo que me impide ver eso. Ahora, si hago clic en Facebook, recuerda que bloqueamos Facebook. Si hago clic en eso, me llevará a una página no encontrada. Esto se debe a que le dijimos que no lo admitimos y esta es una página personalizada que puedes diseñar tú mismo. Es solo una página HTML estática, pero si hago clic en Twitter, dirá que voy a autenticarme con Twitter. Te pedirá permiso si aún no lo has hecho y te llevará de vuelta a la misma página. Ahora, si hago clic en la lista, como estoy autenticado, puedo ver todos los productos. Si hago clic en descuentos, no puedo. Eso se debe a que el usuario debe estar en el rol preferido. Así que si cierro sesión e inicio sesión con GitHub, en realidad estoy autenticado en el rol preferido de GitHub. Ahora puedes ver mis descuentos. ¿Cómo funciona esto? En la aplicación, te mostraré dónde se configura esto. Ve a la gestión de roles, y en la gestión de roles, verás que John Papa en GitHub tiene el rol preferido, así como anónimo y autenticado. Si quisiera agregar a alguien más, lo invitaría, elegiría el proveedor, escribiría algo aquí, como mi hija, agregaría algo como rol preferido y haría clic en generar, y se crea un enlace de invitación que puedes caducar en una hora, 24 horas, etc. Así que pueden hacer clic en él y unirse al rol. Así es como lo configuramos

11. Introducción a Azure Static Web Apps

Short description:

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.

autenticación. Así que acabamos de hacer todas estas cosas, ¿verdad? Es como, ¡guau! Está construido para todas estas diferentes características que tenemos. Obtenemos todo lo que queríamos de la caja. Realmente no tenemos que hacer mucho más para lograrlo, aparte de construir nuestra aplicación, y lo obtenemos todo con Azure Static Web Apps. Todo está en una sola cosa fácil de usar. En este momento está en versión de vista previa, por lo que también estamos buscando comentarios sobre lo que más te gustaría. Acaba de ser lanzado, creo que el 19 de mayo, esa es la fecha de apertura. Obtienes ese flujo de trabajo unificado a través de GitHub Actions, APIs sin servidor, si los deseas, con Azure Functions. No necesitas APIs con serverless, no tienes que usarlos, y está integrado con autenticación y autorización para roles y acceso. Así que si quieres probar esto tú mismo, puedes hacer todo lo que te acabo de mostrar yendo aquí al enlace, SWADocs, toneladas de documentación, y hay 18 páginas que te muestran cómo hacer diferentes cosas, incluyendo dominios personalizados. También puedes probar un tutorial con cosas como Angular FilterView de React, o puedes probar algo como Gatsby. Tenemos un tutorial para Gatsby, tenemos documentación para Hugo, para VuePress, todo tipo de cosas geniales disponibles. Y luego puedes construir

QnA

Gratitude, Frameworks, and Global Distribution

Short description:

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.

Puedes construir la aplicación tú mismo y alcanzar una escala global. Quiero agradecerles por venir hoy y agradezco a todos los de JS Nation por su apoyo, y espero que todos tengan un gran día y den un saludo a Static Web Apps. ¡Guau, John! Como hoy es el cumpleaños de Sir Paul McCartney, voy a describir tu presentación como fabulosa y bastante genial también. Si no te importa aparecer en el centro de interrogación virtual, te haré algunas preguntas de nuestra encantadora audiencia, si eso está bien.

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

Short description:

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

Short description:

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.

nuestra página de GitHub. Así que te remito nuevamente a que vayas allí para agregarlo hoy. No, pero ha habido preguntas sobre Okta. Ha habido preguntas sobre Auth0. Ha habido preguntas sobre SAML. Por favor, agrega tus comentarios en los problemas de GitHub. Y no estoy bromeando cuando digo que están literalmente revisando activamente estos comentarios hoy. Hace aproximadamente media hora tuve una conversación con el equipo sobre algunas de estas cosas. Así que ve allí. Agrega tus comentarios. Haz que tus amigos también lo hagan. Excelente. Gracias. Y tal vez dijiste que podrías poner el enlace en Twitter para que las personas puedan seguir el enlace a GitHub. Absolutamente. Una vez que terminemos de hablar, podré prestarte atención. La última pregunta es posiblemente la más importante. Si estuvieras organizando una cena y me hubieras invitado, porque ¿por qué no lo harías?, a Napoleón y Cleopatra, ¿qué cocinarías? Bueno, primero, soy muy italiano. Me encanta la comida italiana. Así que tendría que ser algo con mucha salsa, queso, fideos y carne todo junto. Una lasaña sería algo increíble de tener. Por supuesto, es un antipasto antes de la comida. Pero la comida no es la parte importante aquí. La parte importante es la conversación. ¿Te imaginas tener la oportunidad de hablar con Cleopatra y Napoleón y yo contigo? Eso sería bastante genial. Sí, al principio pensé que tal vez a Cleopatra no le gustaría la comida italiana. Pero luego supongo que como tuvo un tórrido romance con Marc Anthony y Julio César, que eran italianos, en algún momento habrían cocinado una lasaña, ¿te lo imaginas? ¿Pensarías eso, esperarías eso? Si estuviera tratando de seducir a una emperatriz egipcia, cocinaría una lasaña. Quédate, por favor, John. Y ve a la sala de los oradores donde puedes responder preguntas de los asistentes pagados. En la sala de Zoom. Muchas gracias por tu charla. Fue realmente genial.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London 2023Vue.js London 2023
14 min
Domain Driven Design with Vue Applications
Introduction to Domain Driven Design- What is DDD?- Key principles of DDD- Benefits of using DDD in web application developmentDomain Modeling in Vue 3 Applications- How to design and implement domain models in Vue 3- Strategies for integrating domain logic with Vue's reactive data model and component-based architectureBest Practices for Implementing DDD in Vue 3- Strategies for organizing code in a way that follows DDD principles- Techniques for reducing coupling between domain and application logic- Tips for testing and debugging domain logic in Vue 3 applications
React Summit 2022React Summit 2022
7 min
How to Share Code between React Web App and React Native Mobile App in Monorepo
Usually creating web and mobile apps require different tech stacks, and it is pretty hard to share code. This talk will show how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between react web app and react native mobile app.
JSNation 2022JSNation 2022
23 min
The Next Wave of Web Frameworks is BYOJS
Web application development has had many shifts over the lifetime of the web. From server-side applications with a sprinkle of JavaScript to Single Page Applications built entirely with JavaScript. Now we’re heading back to where many new web frameworks build for static first, with JavaScript added as needed. This talk covers building web applications with JavaScript through the lens of Astro, a static site generator where the choice of JavaScript framework is uniquely yours.
JSNation 2022JSNation 2022
28 min
MIDI in the Browser... Let's Rock the Web!
If you own an electronic music instrument made in the last 3 decades, it most likely supports the MIDI protocol. What if I told you that it is possible to interact with your keytar or drum machine directly from your beloved browser? You would go crazy, right? Well, prepare to do so…With built-in support in Chrome, Firefox and Opera, this possibility is now a reality. This talk will introduce the audience to the Web MIDI API and to my own WEBMIDI.js library so you can get rockin' fast.Web devs, man your synths!
React Advanced Conference 2021React Advanced Conference 2021
24 min
Reusing App State in React Native with Recoil
A group of volunteers all over the world is working on React and React Native apps for the ADHD America program (non-for profit organization). In our work we use Recoil - quite a new React state management tool that looks quite promising. I'll show how we use it in both apps - for web and for mobile and explain why we decided to try it.

Workshops on related topic

JSNation 2022JSNation 2022
141 min
Going on an adventure with Nuxt 3, Motion UI and Azure
WorkshopFree
We love easily created and deployed web applications! So, let’s see what a very current tech stack like Nuxt 3, Motion UI and Azure Static Web Apps can do for us. It could very well be a golden trio in modern day web development. Or it could be a fire pit of bugs and errors. Either way it will be a learning adventure for us all. Nuxt 3 has been released just a few months ago, and we cannot wait any longer to explore its new features like its acceptance of Vue 3 and the Nitro Engine. We add a bit of pizzazz to our application with the Sass library Motion UI, because static design is out, and animations are in again.Our driving power of the stack will be Azure. Azure static web apps are new, close to production and a nifty and quick way for developers to deploy their websites. So of course, we must try this out.With some sprinkled Azure Functions on top, we will explore what web development in 2022 can do.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)