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

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

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í.

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.

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

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.

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