1. Introducción a Jamstack Deploy
Esta es una introducción a un proyecto en el que estuve trabajando en las últimas semanas, donde intenté medir y probar los proveedores de nube más populares para Jamstack. Jamstack es una arquitectura diseñada para hacer que la web sea más rápida, segura y fácil de usar. Ofrece un mejor rendimiento, seguridad y escalabilidad. Los generadores de sitios como Next, Hugo y Nuxt se utilizan comúnmente para crear aplicaciones Jamstack. El proceso de implementación requiere proveedores que ofrezcan soporte SSL.
Hola a todos, bienvenidos a mi charla. Esto es Jamstack Deploy, y es una introducción a un proyecto en el que estuve trabajando en las últimas semanas, donde intenté medir y probar los proveedores de nube más populares para Jamstack. Así que mi nombre es Nacho Anasha, soy de Argentina, aquí tienen mi nombre de usuario de Twitter. Trabajo como Ingeniero Líder de Código Abierto en la República Checa. Soy parte de los equipos externalizados. Este es un aviso legal para la charla, es un proyecto en una etapa temprana, por lo que las cosas podrían cambiar en el futuro, pero espero que puedan tener una idea y puedan comenzar a usarlo como un recurso útil, cada vez que deseen probar un proveedor Jamstack. Así que comencemos hablando sobre Jamstack. Comenzando con lo nuevo, esto es probablemente algo que han escuchado mucho en los últimos meses sobre las API y el marcado de JavaScript, que básicamente son las cosas principales sobre Jamstack. Jamstack no es un marco de trabajo, Jamstack es una arquitectura diseñada para hacer que la web sea más rápida, segura y fácil de usar. Y, por supuesto, también más fácil de escalar. Pueden ir a Jamstack.com para obtener más información. Pero básicamente, las principales características de Jamstack son que se obtiene un mejor rendimiento, principalmente porque construimos todo en tiempo de implementación, no en tiempo real. Por lo tanto, el usuario no necesita esperar el contenido. El contenido ya está ahí. Luego utilizamos servidores web, enviamos todo a través de CDNs. Por lo tanto, todo es estático. Es más seguro porque es una especie de enfoque de microservicio y también puedes confiar en API de terceros. Entonces, si no tienes los recursos para ocuparte de la seguridad, puedes delegar en algo como Auth0. También es más económico y más fácil de escalar porque la forma de escalar es enviar partes del mundo, como replicar tus archivos o servir archivos estáticos en más lugares. Estas son las cosas principales sobre Jamstack. Luego tienes generadores de sitios o generadores de sitios estáticos como Next, Hugo, Nuxt. Esas son las principales herramientas que usas todos los días para crear aplicaciones Jamstack. Y este es el tipo de arquitectura donde comparamos la estructura clásica de una aplicación web con la aplicación web Jamstack. Pueden ver a la derecha que Jamstack es bastante sencillo. Es solo un cliente, una CDN donde enviamos los archivos y microservicios que son como cajas de seguridad. Como desarrolladores, realmente no nos importa lo que hacen o cómo lo hacen, solo necesitamos implementarlos. Por lo tanto, es una estructura fácil para los desarrolladores de Jamstack.
Entonces es hora de implementar. Nos gustaría implementar nuestra aplicación en cualquier tipo de proveedor. Entonces, ¿qué busco en estos proveedores? Lo primero es que me gustaría tener SSL.
2. Medición de rendimiento y proceso del proyecto
Me gusta tener soporte de Git como PR o integraciones previas. La infraestructura como código es una buena característica. Un proceso de configuración agradable, algo simple y rápido. El rendimiento es el enfoque de este proyecto. El proceso involucró crear una aplicación ficticia y desplegarla en diferentes proveedores. Se utilizó Checkly como herramienta de monitoreo para medir el rendimiento. Las comprobaciones se ejecutaron en diferentes regiones de AWS para obtener información de todo el mundo. El tiempo de primer byte se utilizó como unidad de medida. El proyecto Jamstack deploy está en la etapa beta temprana.
soporte de Git de forma nativa. Me gusta tener soporte de Git como PR o integraciones previas.
CLI, amo la
terminal, me gustaría hacer todo a través de mi
terminal. Pero también me gustaría tener una interfaz de usuario agradable donde no tenga mi computadora o algo así, ya sabes, donde pueda escribir código para poder ir a la interfaz de usuario y hacer cosas rápidas. La infraestructura como código es una buena característica porque te permite crear o crear infraestructura utilizando XAML, JSON o incluso código y no todo va a la interfaz de usuario. Un proceso de configuración agradable, algo simple y rápido. Dominios. Siempre necesito un dominio personalizado para mis sitios, a un precio lo más bajo posible. Rendimiento y cola de aprendizaje. Rendimiento es el enfoque de este proyecto y la cola de aprendizaje futura también lo será porque intentaré tener tutoriales o cosas que intenten mostrar cómo usar esos proveedores.
Entonces, ¿cómo fue el proceso de este proyecto? Lo primero que hice fue crear una aplicación ficticia. Es una aplicación Nuxt en el sitio estático. Así que creé exactamente la misma aplicación y la desplegué en diferentes proveedores. Comencé con Verzol, Medlify, Firebase, Render, GitHub, Pages y Search. Una vez que desplegué exactamente la misma aplicación en ellos, fui a Checkly. Checkly es una herramienta de monitoreo. Es básicamente el pilar de este proyecto. Es lo que estoy usando para medir los diferentes proveedores. Y con Checkly puedo crear comprobaciones. Básicamente, una comprobación es una especie de solicitud donde intento medir el rendimiento y obtener estadísticas de esta comprobación donde puedo ver el tiempo de respuesta, el tiempo de primer byte, etc. Y lo que hice con estas comprobaciones utilizando Checkly fue intentar ejecutar todas ellas en diferentes regiones de AWS, en todas las regiones posibles, para obtener diferentes perspectivas de diferentes partes del mundo. No es lo mismo si soy de Argentina, si soy de Estados Unidos o si soy de Sudáfrica. Y junté todas estas piezas utilizando JavaScript y decidí utilizar el tiempo de primer byte como unidad de medida para el proyecto. Y según Google, 200 milisegundos es un buen número para eso. Así que me gusta mantenerme con ese número. Así que junté todo con JavaScript, Vue.js y la API pública de Checkly para poder mostrar toda la información al público sin tener que usar o pasar por la interfaz de usuario de Checkly. Así que puedes ir a esa URL, también puedes ir al repositorio y encontrarás algo como esto.
El proyecto de implementación de Jamstack está en una etapa temprana, realmente beta ahora, pero probablemente sea el comienzo de algo más grande. Puedes elegir tu proveedor, verás que hay más proveedores que llegarán pronto. Entonces, si haces clic en un proveedor como Rocell o Netlify, verás algo como esto.
3. Introducción al Mapa de Rendimiento y Planes Futuros
Esta parte presenta un mapa que muestra el rendimiento de una aplicación Next.js desplegada en modo estático en diferentes proveedores. El mapa muestra las regiones donde se realizaron comprobaciones de rendimiento, con verde indicando por debajo de 200 milisegundos, amarillo entre 200 y 500 milisegundos, y rojo para valores más altos. También se encuentra disponible una lista de los tiempos más rápidos. El orador planea agregar más estadísticas y herramientas para comparación y pruebas A/B. Invita a los usuarios a visitar jumpstartdeploy.com, contribuir al proyecto y comunicarse en Twitter para preguntas.
Esto. Un bonito mapa donde puedes ver todas las regiones que ejecutan comprobaciones en este despliegue del sitio. Recuerda que es una aplicación
Next.js desplegada en modo estático en diferentes proveedores. La misma aplicación, para poder ver cómo se desempeña esta aplicación en las diferentes regiones. Si solicito o intento medir el rendimiento desde Estados Unidos, desde Australia, desde Japón, desde cualquier parte del mundo, obtendré el mapa con los diferentes puntos. Todo lo verde está por debajo de 200 milisegundos. Entre 200 y 500 verás amarillo y más grande que eso verás rojo. Así que, también tienes una lista donde puedes obtener el tiempo más rápido, siempre hablando del primer byte. Pero en el futuro agregaré más estadísticas y herramientas donde puedas compararlos e incluso hacer una prueba A, B. Así que, puedes ir a jumpstartdeploy.com y comenzar y por supuesto, se aceptan PR. Mi lista de tareas pendientes es tratar de brindar una mejor experiencia de usuario en A versus B, como Netlify versus Bercel o Netlify versus Render o cualquier otro, y más tutoriales donde pueda mostrarte cómo usarlos y cuáles son las principales características de esos proveedores y por supuesto, más proveedores como
AWS,
Cloudflare, Microsoft
Azure y otros más. Eso es todo. Muchas gracias. Si tienes preguntas, puedes contactarme en Twitter. Cualquier comentario también es bienvenido, así que espero que disfrutes el resto de la conferencia.
React Summit 2023
Comments