Fundamentos de JAMstack: qué, qué y cómo

Nos encanta traspasar los límites de la web, por lo que hemos decidido probar algo nuevo. Probablemente haya oído hablar de JAMstack, la nueva pila web basada en JavaScript, API y marcado, pero ¿qué significa para su flujo de trabajo y cuándo tiene sentido en sus proyectos?

Como parte de nuestra Membresía Smashing, realizamos Smashing TV , una serie de seminarios web en vivo, todas las semanas. Sin rodeos: solo seminarios web prácticos y procesables con preguntas y respuestas en vivo, a cargo de profesionales muy respetados de la industria. De hecho, el horario de Smashing TV ya parece bastante denso, y es gratis para los miembros de Smashing, junto con las grabaciones, obviamente .

Le pedimos amablemente a Phil Hawksworth que realice un seminario web que explique qué significa realmente JAMStack y cuándo tiene sentido, además de cómo afecta las herramientas y la arquitectura de front-end. El seminario web de una hora de duración ya está disponible también. No podríamos estar más felices de dar la bienvenida a Phil como co-presentador de nuestra próxima SmashingConf Toronto (25 y 26 de junio) y dirigir JAMStack_conf London, que también organizamos el 9 y 10 de julio de este año. Entonces, ¡vamos a hacerlo!

Phil Hawksworth: Excelente, está bien, entonces entremos en materia. Solo a modo de hola muy rápido, quiero decir que ya he dicho hola, Scott me ha dado una buena presentación. Pero sí, actualmente trabajo en Netlify, trabajo allí en el equipo de experiencia del desarrollador. Esperamos tener mucho tiempo para preguntas y respuestas, pero, como mencionó Scott, si no tiene la oportunidad de hacer preguntas allí, o si simplemente lo prefiere, puede enviarlas directamente a mí en Twitter, así que mi cuenta de Twitter es mi nombre, es Phil Hawksworth, por lo que en cualquier momento puede hacerme preguntas sobre JAMstack o cualquier cosa en Twitter.

Phil Hawksworth: Pero quiero comenzar hoy retrocediendo un poco en el tiempo a esta cita que realmente resuena muy, muy fuerte en mí. Esta es una cita del maravilloso Aaron Schwartz quien, por supuesto, contribuyó mucho a Creative Commons y la web abierta y escribió esto en su blog en 2002, y dijo: "Me importa no tener que mantenerme irritable". Se instala el servidor AOL, Postgres y Oracle”. servidor de AOL, tuve que mirar hacia arriba para recordar que era un servidor web de código abierto en ese momento.

Phil Hawksworth: Pero esto me suena muy fuerte. Tampoco quiero mantener la infraestructura para mantener vivo un blog, y de eso estaba hablando. Y fue en esta publicación de blog en su propio blog y se tituló "Hornear, no freír". Estaba eligiendo un término que alguien que había creado un CMS recientemente había comenzado a usar, y popularizó este término sobre hornear (Hornear, no freír); de lo que está hablando allí es pre-renderizado en lugar de renderizado bajo demanda, por lo que preparar el contenido con anticipación, en lugar de freírlo bajo demanda cuando la gente viene y lo pide, alejando las cosas del tiempo de solicitud y en una especie de tiempo de construcción.

Phil Hawksworth: Y cuando hablamos de renderizado previo y renderizado, lo que queremos decir con eso es que estamos hablando de generar marcado. A veces me siento un poco cohibido al hablar sobre el tipo de renderizado del servidor o el renderizado isomorfo o muchos de estos términos de moda; Me llamaron la atención hace unos años en una conferencia, Frontiers Conference en Amsterdam, cuando estaba hablando sobre el renderizado en el servidor y alguien me dijo: “¿Te refieres a generar HTML? ¿Solo algo que genera HTML? Y eso es, por supuesto, lo que quiero decir.

Phil Hawksworth: Pero todo esto contribuye en gran medida a simplificar la pila. Cuando pensamos en la pila desde la que servimos sitios web; Me gusta tratar de simplificar las cosas, estoy muy interesado en tratar de simplificar la pila. Y eso es algo así como el corazón de esta cosa llamada "JAMstack" y quiero tratar de explicar esto un poco. El "JAM" en JAMstack significa JavaScript, API y marcado. Pero eso no es suficiente para ayudarnos a entender lo que significa, ¿qué diablos significa eso realmente?

Phil Hawksworth: Bueno, lo que quiero intentar hacer en la próxima media hora es ampliar esa definición y dar una descripción más detallada de lo que es JAMstack. Quiero hablar un poco sobre el impacto y las implicaciones de JAMstack y, ya sabes, pensar en lo que eso puede darnos sobre por qué podríamos elegirlo. En el camino, trataré de mencionar algunas de las herramientas y servicios que serán útiles y, con suerte, terminaré con algunos recursos en los que tal vez desee profundizar y quizás mencione algunos primeros pasos para ayudarlo. en marcha.

Phil Hawksworth: Ese es el plan para la próxima media hora. Pero, más o menos, quiero volver a esta noción sobre la simplificación de la pila porque, con suerte, las personas que se unan a esto o hayan venido a ver este video más adelante, tal vez tengan una noción de lo que es JAMstack, o tal vez es un término completamente nuevo, y solo tienes curiosidad. Pero, en última instancia, ya hay muchas pilas por ahí. Hay muchas maneras en las que puede entregar un sitio web. Se siente como si hubiéramos estado construyendo diferentes tipos de infraestructura durante mucho tiempo, ya sea una pila LAMP o la pila MAMP, o, no sé, la pila MEAN. Hay un montón de ellos flotando en la pantalla aquí. Hay montones y montones de ellos.

Phil Hawksworth: Entonces, ¿por qué demonios necesitaríamos otro? Bueno, JAMstack es, como mencioné, JavaScript/API/Markup, pero si tratamos de ser un poco más descriptivos, JAMstack pretende ser una arquitectura moderna, para ayudar a crear sitios rápidos y seguros y aplicaciones dinámicas con JavaScript/ Las API y el marcado prerenderizado, se sirven sin servidores web, y es este último punto lo que lo distingue y, tal vez, lo hace un poco más interesante e inusual.

Phil Hawksworth: Esta noción de servir algo sin servidores web suena mágica o ridícula y, con suerte, descubriremos qué es en el camino. Pero para tratar de arrojar algo de luz sobre esto y describirlo con un poco más de detalle, a veces es útil compararlo con lo que podríamos considerar como una pila tradicional, o una forma tradicional de servir cosas en la web. Entonces, hagámoslo solo por un segundo. Veamos, tal vez, cómo se vería una solicitud a medida que se atiende en una pila tradicional.

Phil Hawksworth: Entonces, en este escenario, alguien abrió un navegador web y solicitó ver una página. Y tal vez esa solicitud llegue a una CDN, pero probablemente, más probablemente, llegue a alguna otra infraestructura que hospedamos, como las personas propietarias de este sitio. Tal vez tratamos de asegurarnos de que esto escalará bajo mucha carga porque, obviamente, queremos una vista muy popular y exitosa. Entonces, tal vez tenemos un balanceador de carga, que tiene algo de lógica, que atenderá esa solicitud a uno de varios servidores web que hemos aprovisionado, configurado e implementado. Puede haber varios de esos servidores.

Phil Hawksworth: Y esos servidores ejecutarán cierta lógica para decir: "Está bien, aquí está nuestra plantilla, necesitamos completarla con algunos datos". Podríamos obtener nuestros datos de uno de varios servidores de bases de datos que ejecutarán alguna lógica para buscar algunos datos, devolverlos al servidor web, crear una vista que luego pasaremos a través del balanceador de carga. Tal vez, en el camino, llame a CDN, guarde algunos activos en CDN, y debo aclarar, un CDN es una red de entrega de contenido, por lo que una red de máquinas distribuidas por Internet para tratar de obtener el servicio de solicitud lo más cerca posible al usuario y agregar cosas, como el almacenamiento en caché.

Phil Hawksworth: Entonces, podríamos esconder algunos activos allí y, en última instancia, devolver una vista al navegador, a los globos oculares del usuario, que luego experimenta el sitio que creamos. Entonces, obviamente, eso es, ya sea, una simplificación excesiva o una visión muy general de cómo podemos atender una solicitud en una pila tradicional. Si comparamos eso con JAMstack, que está dando servicio a las cosas de una manera ligeramente diferente, así es como podría verse.

Phil Hawksworth: De nuevo, el mismo escenario, estamos comenzando en un navegador web. Estamos solicitando una vista de la página, y esa página ya está en un CDN. Sirve estáticamente desde allí, por lo que se devuelve al usuario, al navegador y listo. Entonces, obviamente, una vista muy simplificada, pero de inmediato, puedes comenzar a ver las diferencias aquí en términos de complejidad. En términos de lugares en los que necesitamos administrar el código, codificar profundamente, todas esas cosas diferentes. Entonces, para mí, uno de los atributos principales de un JAMstack es que significa que está creando un sitio que se puede servir directamente desde una CDN, o incluso desde un servidor de archivos estático. CDN es algo que podríamos querer implementar para manejar la carga, pero en última instancia, esto podría servirse directamente desde cualquier tipo de servidor de archivos estático, tipo de infraestructura de alojamiento estático.

Phil Hawksworth: JAMstack, más o menos, ofrece la oportunidad de reducir la complejidad. Simplemente comparando esas dos partes del diagrama a las que volveremos varias veces, en el transcurso de la próxima media hora, puede ver que es una oportunidad para reducir la complejidad y reducir el riesgo. Entonces, significa que podemos comenzar a disfrutar de algunos de los beneficios de servir activos estáticos, y hablaré sobre cuáles son un poco más adelante. Pero es posible que esté mirando esto y pensando: "Bueno, genial, pero ¿no es este solo el nuevo nombre para los sitios web estáticos?" Eso es algo razonable para señalarme cuando digo: "Vamos a servir las cosas de forma estática".

Phil Hawksworth: Pero quiero volver a eso. Quiero hablar un poco más sobre eso, pero antes que nada, quiero, más o menos, hablar sobre esta noción de pilas y qué diablos es una pila, de todos modos. Y pienso en una pila como las capas de tecnología que entregan su sitio web o aplicación. Y no estamos hablando de la tubería de construcción o el proceso de desarrollo, pero ciertamente la forma en que servimos los sitios puede tener un gran impacto en cómo desarrollamos y cómo implementamos las cosas, y así sucesivamente.

Phil Hawksworth: Pero aquí, estamos hablando de la pila de tecnología, las capas de tecnología, que realmente entregan su sitio web y su aplicación a los usuarios. Entonces, hagamos otra pequeña comparación. Hablemos de la pila LAMP por un segundo.

Phil Hawksworth: La pila LAMP, como recordará, se compone de un servidor web apache, para hacer cosas como el enrutamiento HCP y el servicio de activos estáticos. PHP, para un poco de preprocesamiento, así que un bonito procesamiento de hipertexto; aplicando la lógica, tal vez construyendo las vistas para las plantillas y lo que sea. Y tiene algún acceso a sus datos, por mi NISQL, y luego LINUX es el sistema operativo que se encuentra debajo de todo eso, mantiene todo respirando. Podemos envolver eso juntos teóricamente como este servidor web. Y es posible que tengamos muchos de estos servidores, más o menos, sentados juntos para servir un sitio web.

Phil Hawksworth: Esa es una especie de mirada tradicional a la pila LAMP, y si la comparamos con la JAMstack, bueno, aquí hay un cambio crítico. Aquí, en realidad estamos subiendo de nivel, en lugar de pensar en el sistema operativo y pensar en cómo ejecutamos la lógica para ofrecer un sitio web. Aquí estamos asumiendo que vamos a estar sirviendo estas cosas de forma estática. Entonces, estamos haciendo el enrutamiento ACP y el servicio de activos desde un servidor estático. Eso se puede hacer razonablemente. Nos volvimos muy buenos en esto, a lo largo de los años, creando formas de entregar sitios web estáticos o activos estáticos.

Phil Hawksworth: Esto podría ser un CDN y, de nuevo, hablaremos de eso en un momento. Pero el área de interés para nosotros está sucediendo más en el navegador. Entonces, aquí, aquí es donde se entrega y se analiza nuestro marcado. Aquí es donde se puede ejecutar JavaScript, y esto está sucediendo en el navegador. En muchos sentidos, el navegador se ha convertido en el tiempo de ejecución de la web moderna. En lugar de tener el tiempo de ejecución en la infraestructura del servidor, ahora lo hemos movido a un nivel superior, más cerca del usuario y en el navegador.

Phil Hawksworth: Cuando se trata de acceder a datos, bueno, eso sucede, posiblemente, a través de API externas, haciendo llamadas a través de JavaScripts a estas API externas para obtener acceso al servidor, o podemos pensar en las API como las API del navegador, pudiendo interactuar con JavaScript. con capacidades allí mismo en su navegador.

Phil Hawksworth: De cualquier manera, la clave aquí sobre JAMstack es que estamos hablando de cosas que están renderizadas previamente: se sirven de forma estática y luego, pueden mejorarse progresivamente en el navegador para hacer uso de las API del navegador, JavaScripts. , y lo que tienes.

Phil Hawksworth: Entonces, hagamos esta pequeña comparación lado a lado aquí. Nuevamente, solo quiero reiterar que JAMstack ha subido un nivel al navegador. Y si vemos los dos lados de este diagrama, con la pila LAMP a la izquierda y efectivamente, la JAMstack a la derecha, incluso podrías pensar que, bueno, incluso cuando estábamos construyendo cosas con la pila LAMP, todavía estamos marcado de salida. Todavía estamos generando JavaScript. Es posible que todavía estemos accediendo a las API. Entonces, en muchos sentidos, JAMstack es casi como un subconjunto de lo que estábamos construyendo antes.

Phil Hawksworth: A veces solía hablar de JAMstack como la pila segura, porque asegura un conjunto de herramientas y tecnologías que necesitamos para entregar un sitio. Pero, de cualquier manera, es una forma mucho más simplificada de entregar un sitio que, en cierto modo, elimina la necesidad de que las cosas se ejecuten y realicen la lógica en el servidor en el momento de la solicitud.

Phil Hawksworth: Entonces, esto puede hacer muchas cosas. Esto puede, en cierto modo, simplificar las implementaciones y, de nuevo, volveré a llamar a este diagrama de vez en cuando. Si pensamos en cómo implementamos nuestro código y nuestro sitio, para cada implementación, desde la primera, a lo largo de todo el ciclo de vida del desarrollo, durante toda la vida del sitio web. En la pila tradicional, es posible que tengamos que cambiar la lógica y el contenido de cada cuadro en ese diagrama.

Phil Hawksworth: Mientras que, en JAMstack, cuando hablamos de implementación, hablamos de llevar cosas a la CDN, llevar cosas al servidor estático, y eso es lo que implica la implementación. La compilación, el tipo de lógica que ejecuta la compilación, que puede ejecutarse en cualquier lugar. Eso no necesita ejecutarse en el mismo entorno que aloja el servidor web. De hecho, ¡no es así! Inicia la clave para el JAMstack. Ponemos la separación en lo que sucede en el momento de la solicitud, sirviendo estos activos estáticos, frente a lo que sucede en el momento de la compilación, que puede ser su lógica que ejecuta para compilar y luego para la implementación.

Phil Hawksworth: Entonces, este tipo de disociación es clave, y volveré sobre eso más adelante. Somos muy buenos para servir archivos estáticos, y llevar cosas a un CDN o llevar cosas al sistema de archivos (el servidor de archivos) es algo en lo que hemos visto un gran avance en los últimos años. Ahora hay muchas herramientas y procesos que pueden ayudarnos a hacer esto muy bien. Solo para mencionar algunos servicios que pueden servir bien a los activos estáticos y brindar flujos de trabajo para llevar su compilación a ese entorno, son los sospechosos habituales que podría imaginar a los grandes proveedores de infraestructura de nubes, como Azure, AWS y Google Cloud.

Phil Hawksworth: Pero luego, hay otros. Entonces, el de arriba a la derecha es un servicio llamado Surge, que existe desde hace algunos años. Le permite ejecutar un comando en su entorno de compilación e implementar sus activos a través de su entorno de alojamiento. Netlify, el siguiente, es donde trabajo y hacemos prácticamente lo mismo, pero también tenemos una automatización diferente. Podría entrar en ello en otro momento. Y el de abajo, otro sitio de entorno de alojamiento estático, llamado Now.

Phil Hawksworth: Entonces, hay un montón de opciones diferentes para hacer esto, y todos estos espacios proporcionan diferentes herramientas para llegar a la CDN, lo más rápido posible. Lograr que sus sitios se implementen de la manera más sencilla posible. Y todos tienen algo en común en el que se basan en el principio de ejecutar algo localmente. A menudo pienso en un generador de sitios estáticos como algo que podríamos ejecutar en una compilación que, cuando lo ejecutamos, toma cosas como contenido y plantillas y, tal vez, datos de diferentes servicios y genera algo que se puede servir de forma estática.

Phil Hawksworth: Podemos obtener una vista previa localmente en nuestro servidor estático. Algo que es bastante simple de hacer en cualquier entorno de desarrollo local, y luego el proceso de implementación lo lleva al entorno de alojamiento e, idealmente, a una CDN para obtener, más o menos, escala. Entonces, con ese tipo de base establecida, quiero abordar un concepto erróneo común cuando se trata de sitios JAMstack. Y no me hice ningún favor al abrir esto describiendo los sitios JAMstack como JavaScript, API y Markup. Porque el concepto erróneo común es que cada sitio JAMstack tiene que ser JavaScript y API, y Markup, pero este tipo de cosas que hemos pasado por alto es que no tenemos que usar los tres, cada uno de estos es, más o menos , Opcional. Podemos usar tanto o tan poco como queramos. De la misma manera que un sitio de pila LAMP no necesariamente tendría que estar accediendo a una base de datos. Ahora, construí cosas en el pasado que son atendidas por un servidor apache, en una máquina Linux, y he estado usando PHP, pero no he estado accediendo a una base de datos y no comenzaría a cambiar el nombre de una pila. necesariamente por eso.

Phil Hawksworth: Entonces, si pensamos en lo que es un sitio JAMstack, entonces podría ser un montón de cosas diferentes. Podría ser algo construido con un generador de sitios estáticos, como Jekyll, extrayendo contenido de archivos YAML para crear un sitio que no tenga JavaScript, que no utilice las API en absoluto, y lo servimos en algo, como Páginas de GitHub. O bien, ese sería un sitio JAMstack. O tal vez estamos usando un generador de sitios estáticos, como Gatsby, que está, más bien, en un entorno Ruby para Jekyll, ahora este es un generador de sitios estáticos de JavaScript integrado en el ecosistema React.

Phil Hawksworth: Eso podría estar extrayendo contenido nuevamente y está organizando archivos Markdown. Podría ser enriquecedor eso con llamadas a las API, las API de GraphQL. Podría estar haciendo cosas en el navegador, como hidratar JavaScript para completar plantillas allí mismo en el navegador. Y podría servirse en Amazon S3. ¿Es ese un sitio JAMStack? ¡Si absolutamente!

Phil Hawksworth: Pasando a un generador de sitios estáticos diferente, Hugo, que está construido con Go! Nuevamente, podríamos estar organizando contenido en archivos Markdown, agregando interacciones en el navegador usando JavaScript. Tal vez no llame a ninguna API externa y tal vez la aloje en Google Cloud. ¿Es JAMstack? ¡Absolutamente! Verás, estoy construyendo un tema aquí. Usando algo como Nuxt, otro generador de sitios estáticos, ahora integrado en el ecosistema View. ¿Quizás eso es extraer contenido de diferentes archivos adyacentes? Nuevamente, podríamos estar usando interacciones de JavaScript en el navegador, tal vez llamando a las API para hacer cosas como comercio electrónico, sirviendo otro sitio estático. Otra infraestructura de alojamiento como Netlify, ¿es un JAMstack? ¡Sí lo es!

Phil Hawksworth: Pero incluso podríamos ir, ya sabes, ir a este lado de la escala también. Y piense en una aplicación web progresiva y hecha a mano que hemos construido artesanalmente, enrollada a mano, JavaScript que construimos nosotros mismos. Lo estamos empaquetando con webpack. Tal vez estemos usando tokens web de JavaScript y llamando a las API para realizar la autenticación, interactuando con diferentes API del navegador y alojándolo en Azure. ¡Sí, eso también es JAMstack!

Phil Hawksworth: Y, ya sabes, todas estas cosas, y muchas más, pueden considerarse JAMstack, porque todas comparten un atributo en común y es que ninguna de ellas se sirve con un servidor de origen. Ninguno de ellos tiene que acceder a un servidor que realiza la lógica en el momento de la solicitud. Estos se sirven como activos estáticos y luego se enriquecen con JavaScript y llamadas a las API.

Phil Hawksworth: Entonces, nuevamente, solo quiero reiterar que un JAMstack significa que es capaz de ser atendido directamente desde la CDN. Entonces, solo quiero mencionar algunos de los impactos e implicaciones de esto, porque ¿por qué querríamos hacer esto? Bueno, la primera noción es sobre seguridad, y aquí tenemos un área de superficie muy reducida para el ataque. Si pensamos (volviendo de nuevo a este viejo diagrama), los lugares donde podríamos tener que lidiar con un ataque, tenemos que asegurar cosas como el balanceador de carga, los servidores web, los servidores de bases de datos. Todas estas cosas, tenemos que asegurarnos de que no puedan ser penetradas por ningún tipo de ataque y, de hecho, la CDN.

Phil Hawksworth: Si cuantas más piezas podamos sacar de este rompecabezas, menos lugares se pueden atacar y menos lugares tenemos que asegurar. Tener pocas partes móviles para atacar es realmente muy valioso. En Netlify, operamos nuestros propios CDN, por lo que nos damos el lujo de poder monitorear el tráfico que llega, y aunque todos los sitios alojados en Netlify, todos los sitios JAMstack que pueda imaginar, ninguno de ellos tener una página de administración de WordPress en ellos porque está completamente desacoplado. No hay un administrador de WordPress, pero vemos un gran volumen de tráfico, investigando cosas como WP Admin, buscando formas de entrar, buscando vectores de ataque.

Phil Hawksworth: Me encantan algunas de las cosas que ha hecho Kent C. Dodds. No sé si está familiarizado con la comunidad React, probablemente se haya encontrado con Kent C. Dodds en el pasado. No usa WordPress, pero todavía enruta esta URL, el WPAdmin. Creo que solía enrutarlo a través de un video de Rick Roll en YouTube. Ciertamente ha estado troleando a las personas que lo han investigado. Pero, el punto es que, al desacoplar las cosas de esa manera y, de alguna manera, mover las cosas que suceden, construir el tiempo a partir de lo que sucede en el tiempo de solicitud, podemos reducir drásticamente nuestra exposición. No tenemos piezas móviles en el momento de la solicitud. Todas las partes móviles están completamente desacopladas en el momento de la construcción. Potencialmente, completamente, bueno, necesariamente en una infraestructura completamente diferente.

Phil Hawksworth: Esto, por supuesto, también tiene un impacto en el rendimiento. Volviendo a nuestro viejo amigo aquí, los lugares que podríamos querer probar y mejorar el rendimiento en la pila aquí, cuando hay lógica que debe ejecutarse en estos diferentes lugares. La forma en que esto sucede a menudo en las pilas tradicionales es que comienzan a agregar capas, agregan capas estáticas para mejorar el rendimiento. Entonces, en otras palabras, trata de encontrar formas en las que podamos comenzar a comportarnos como si fuera estático. No es necesario realizar esa lógica en cada nivel de la pila para acelerar las cosas. Entonces, estamos comenzando a introducir cosas como el almacenamiento en caché en toda la infraestructura y los lugares obvios que podemos encontrar para hacerlo son en el servidor web, en lugar de realizar esa lógica, queremos servir algo de inmediato sin realizar esa lógica.

Phil Hawksworth: Entonces, es como un paso hacia ser pseudo-estático. Del mismo modo, en los servidores de bases de datos, queremos agregar capas de almacenamiento en caché a las consultas de caché-com. Incluso en el saldo bajo, todo el CDN se puede considerar como un caché. Pero en la pila tradicional, debemos descubrir cómo administrar ese caché, porque no todo se almacenará en caché. Entonces, hay algo de lógica al respecto. Lo que debe completarse dinámicamente frente a lo que se puede almacenar en caché. Y el modelo JAMstack, todo está en caché. Todo se almacena en caché desde el momento en que se realiza la implementación, por lo que podemos pensarlo de manera completamente diferente.

Phil Hawksworth: Esto, entonces, también comienza a insinuar la escalabilidad. Y por escala, me refiero a cómo manejamos grandes cargas de tráfico. Las pilas tradicionales comenzarán a agregar infraestructura para escalar. Entonces, sí, al almacenamiento en caché. Estamos empezando a poner en su lugar en nuestra pila tradicional. Eso ayudará, hasta cierto punto. Lo que suele suceder es que, para manejar grandes cargas de tráfico, comenzamos a expandir la infraestructura y comenzar a agregar más servidores, más piezas para manejar estas solicitudes, calcular el costo de estas cosas y estimar que la carga es una gran sobrecarga y puede ser un dolor de cabeza para cualquiera que haga arquitectura técnica. Ciertamente lo fue para mí, por lo que comencé a inclinarme mucho más hacia el enfoque JAMstack, donde sé que todo se sirve desde la CDN, que está diseñada de forma predeterminada para manejar la escala, para manejar el rendimiento desde el principio. .

Phil Hawksworth: Entonces, también quiero hacer un guiño a la experiencia del desarrollador y el impacto que esto puede tener allí. Ahora, la experiencia del desarrollador nunca debe verse como algo que prevalece sobre la experiencia del usuario, pero creo que una buena experiencia del desarrollador puede reducir la fricción, puede permitir que los desarrolladores hagan un trabajo mucho mejor al crear excelentes experiencias de usuario.

Phil Hawksworth: Entonces, cuando pensamos en dónde vive la experiencia del desarrollador y dónde están aquí las áreas de preocupación para un desarrollador: bueno, en una pila tradicional, es posible que debamos pensar en cómo llevamos el código a todos estos diferentes partes de la infraestructura, y cómo todos ellos juegan juntos. En el mundo de JAMstack, realmente, de lo que estamos hablando es de este cuadro aquí en la parte inferior. Ya sabes, ¿cómo ejecutamos la compilación y ellos, cómo automatizamos una implementación para que algo se sirva en primer lugar? Y lo bueno es que, en el modelo JAMstack, lo que hagas en esa compilación depende completamente de ti.

Phil Hawksworth: Ese es un espacio de problemas muy bien definido, porque en última instancia, estás tratando de construir algo que puedas servir directamente desde un CDN. Desea renderizar previamente algo, utilizando las herramientas que desee: ya sea un generador de sitios estáticos integrado en Ruby, Python, JavaScript, Go o PHP, tiene la libertad de elegir. Y así, eso puede crear un entorno mucho más agradable para que usted trabaje. Y también, crea una oportunidad para tener una confianza real del desarrollador porque un atributo real de los sitios JAMstack es que se pueden servir mucho más fácilmente como implementación inmutable y atómica.

Phil Hawksworth: Y quiero saltar un poco de las diapositivas solo por un momento, para describir lo que eso significa, porque una implementación inmutable y una implementación atómica pueden... (eso puede sonar un poco a jerga de marketing), pero lo que voy a hacer es saltar a mi navegador. Ahora... en realidad, voy a regresar por un segundo. Déjame... solo haz esto.

Phil Hawksworth: Aquí estamos. Esto será más fácil. Saltando directamente a la página. Ahora, Scott, dime, Scott, si no puedes ver mi navegador, espero. Ahora, suponiendo que todos puedan ver mi navegador.

Scott: Todo se ve bien.

Phil Hawksworth: ¡Excelente! ¡Muchas gracias!

Phil Hawksworth: Entonces, lo que estoy haciendo aquí es usar Netlify como ejemplo, como ejemplo del servicio. Pero este es un atributo que es común a los sitios que se pueden alojar de forma estática. Entonces, cuando hablamos de una implementación inmutable, lo que queremos decir es que, en lugar de que cada implementación de código tenga que tocar muchas partes diferentes de la infraestructura y cambiar muchas cosas, aquí no estamos mutando el estado del sitio en el servidor. Estamos creando una instancia completamente nueva del sitio para cada implementación que ha ocurrido. Y podemos hacerlo porque el sitio es una colección de activos estáticos.

Phil Hawksworth: Aquí, estoy viendo la implementación que ha ocurrido desde mi propio sitio web. Te daré un regalo. Ahí estás, eso es lo que parece. Es solo un blog, no parece nada particularmente notable o emocionante. Es un blog generado estáticamente, pero lo que tengo aquí es cada implementación que ha ocurrido, vive a perpetuidad, porque es una colección de activos estáticos que se sirven desde un CDN. Ahora, podría retroceder hasta donde mi historia me permita e ir y mirar el sitio, como estaba en... ¿cuándo fue esto? Esto fue en agosto de 2016. Y en virtud de que es un conjunto de activos estáticos, podemos alojar esto en su propia URL que vive a perpetuidad y, si quisiera, podría decidir entrar y publicar eso. despliegue.

Phil Hawksworth: Entonces, ahora, cualquiera que esté mirando mi sitio web, si vuelvo a mi sitio web aquí, si actualizo esa página, ahora se sirve directamente desde la CDN con los activos que estaban allí antes. Ahora, puedo navegar de nuevo. Aquí puedes ver. Mire, estaba insistiendo en esto, estaba usando estos términos terribles como representación isomorfa y hablando sobre JAMstack en 2016. Entonces, esto es ahora lo que se ofrece en vivo en mi sitio. Nuevamente, porque hay implementaciones mutuas que simplemente viven para siempre. Voy a poner mi propia tranquilidad, voy a, ¿es esta la primera página? Si. Voy a volver a mi último despliegue. Tendré que cerrarme de nuevo y volver al mundo real. Déjame asegurarme de que esto está bien.

Phil Hawksworth: ¡Está bien! ¡Genial! Entonces, ahora, esto es volver a servir mi versión anterior, o mi última versión del sitio. Volveré a la nota clave. Entonces, esto es posible porque las cosas son inmutables y atómicas. La parte atómica de eso significa, nuevamente, que el despliegue está completamente contenido. Por lo tanto, nunca llega al punto en el que algunos de los activos están disponibles en el servidor web, pero otros no. Solo cuando todo está allí en contexto y todo está allí, completo, cambiamos el servicio del sitio a la nueva versión. Una vez más, este es el tipo de cosas que puede hacer mucho más fácilmente si está creando un sitio JAMstack que sirve directamente desde la CDN como un conjunto de activos.

Phil Hawksworth: Me di cuenta de que mi cronómetro se ha reiniciado, después de retroceder y avanzar desde el discurso principal, así que creo que me quedan unos seis o siete minutos. Dime, Scott, si...

Scott: Entonces, sí, todavía estamos bien durante unos diez minutos.

Phil Hawksworth: ¿Diez minutos? Bien, ¡maravilloso!

Scott: No hay prisa.

Phil Hawksworth: ¡Gracias, eso debería ser bueno!

Phil Hawksworth: Entonces, simplemente cambiando un poco de equipo y hablando de API y servicios (dado que las API son parte de JAMstack), el tipo de servicios que luego podríamos usar es principalmente JAMstack. Ya sabes, podríamos estar usando servicios que construimos internamente, o podríamos estar usando servicios comprados. Hay muchos proveedores diferentes que pueden hacer cosas por nosotros, y eso es porque esa es su experiencia. A través de las API, podemos extraer contenido de los sistemas de administración de contenido como un servicio, y hay muchos proveedores diferentes para esto, que se especializan en brindar una excelente experiencia de administración de contenido y luego, exponer el contenido a través de la API, por lo que solía estar capaz de atraerlos.

Phil Hawksworth: Del mismo modo, hay diferentes formas en las que puede entregar activos. Las personas como Cloudary son excelentes en esto, para optimizar imágenes, entregar activos directamente a sus sitios, nuevamente, a través de API. ¿O qué pasa con el comercio electrónico? Ya sabes, hay lugares como Stripe o Snipcart que nos pueden proporcionar API, para que no tengamos que construir estos servicios nosotros mismos y entrar en los problemas muy complejos que surgen al intentar construir un motor de comercio electrónico. Del mismo modo, la identidad, de personas como Auth0 que usan Oauth. Hay muchos servicios disponibles y podemos consumirlos a través de las API, ya sea en el navegador o en el momento de la compilación o, a veces, una combinación de ambos.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hola, todos. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. ¿Derecha? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Realmente me gusta, porque el término JAMstack puede ser muy engañoso, porque está tratando de cubrir muchas cosas diferentes y el punto que estaba tratando, probablemente lo martillé muchas veces en esa diapositiva, es que puede ser de todo tipo. de cosas. Es muy amplio, pero la clave es la representación previa y el alojamiento del núcleo de los sitios de forma estática. Es muy fácil para nosotros entrar en guerras religiosas sobre dónde debe ser un sitio de React. Tiene que ser una aplicación React, para ser un sitio JAMstack, o es una aplicación React, por lo que no puede ser JAMstack. Pero, en realidad, el quid de la cuestión es si usa JavaScript o no, si está llamando a las API o no, si pre-renderiza y obtiene las cosas en un host estático que puede tener un gran rendimiento, ese es el núcleo de JAMstack.

Vitaly: Sí, absolutamente.

Phil Hawksworth: Somos muy afortunados de que los navegadores sean cada vez más capaces, y las API que están dentro de los propios navegadores también pueden permitirnos hacer mucho más. Entonces, eso abre las puertas aún más, pero no significa que todo lo que construimos como un sitio JAMstack tenga que hacer uso de todo. Dependiendo de lo que estemos tratando de entregar, así es como deberíamos comenzar a elegir las herramientas con las que estamos jugando para implementar esas cosas.

Vitali: Absolutamente. Tenemos a Doran aquí. Doran, creo que lo sé, Doran. Tengo la sensación de que conozco a Doran. Él pregunta: “¿Espera que la tecnología sin servidor gravite hacia una integración perfecta con JAMstack desde [inaudible 00:44:36]? Lo que se conoce como la A en JAM.

Phil Hawksworth: Esa es una gran pregunta, porque creo que las funciones sin servidor funcionan muy bien con los sitios JAMstack, porque en muchos sentidos, de hecho, creo que alguien me preguntó una vez si los sitios JAMstack no tienen servidor, así que me inquieté. esa pregunta, porque serverless es un término tan cargado. Pero, en muchos sentidos, es genial porque estaba hablando, una y otra vez, de que no hay un servidor de origen. No hay una infraestructura de servidor que deba administrar. De hecho, una vez escribí una publicación de blog llamada "Web sin servidor", porque el mundo necesita otro término de moda, ¿no es así?

Phil Hawksworth: Y realmente, el tipo de punto de eso fue, sí, estamos construyendo cosas sin servidores. No queremos tener que administrar estos servidores, y las funciones sin servidor, o funciones como servicio, encajan perfectamente en eso. Entonces, en los casos en que necesita una API a la que desea realizar una solicitud, donde realmente no es sensato que realice esa solicitud directamente desde el navegador. Entonces, por ejemplo, si tiene secretos o claves en esa solicitud, es posible que no desee que esas solicitudes, esa información, se expongan nunca en el cliente. Pero ciertamente podemos hacer proxy de esas cosas y, por lo general, tradicionalmente, lo que debemos hacer entonces es activar un servidor, tener una infraestructura que efectivamente estaba haciendo poco más que manejar solicitudes, agregarle autenticación de seguridad y pasar esas solicitudes a , devolviéndolos por proxy.

Phil Hawksworth: Las funciones sin servidor son perfectas para eso. Son absolutamente ideales para eso. Entonces, a veces pienso en funciones sin servidor, o funciones de un servicio, casi como una escotilla de escape, donde solo necesitas algo de lógica en un servidor, pero no quieres tener que crear una infraestructura completa. Y puede hacer más y más con eso, y establecer las canalizaciones de desarrollo para flujos de trabajo de desarrollo, para funciones a medida que un servicio está madurando. Cada vez es más accesible para los desarrolladores de JavaScript poder desarrollar estas cosas. Entonces, sí, realmente creo que esas dos cosas van muy bien juntas.

Vitaly: Muy bien, esa es una respuesta muy completa. De hecho, asistí a una charla recientemente, en la que un ingeniero de front-end de Amazon hablaba sobre las funciones sin servidor y Lamda que están usando. Casi me había ido. Siempre estaba hablando de Docker, Kubernetes y todas esas cosas, Devox World, yo estaba sentado allí, pensando: "¿Cómo terminó allí? ¡No entiendo lo que está pasando!” No tenía idea de lo que está pasando.

Phil Hawksworth: Exacto, pero la cosa es que solía ser el… Yo era… Acepté que no entendía nada de ese mundo, pero no tenía ningún deseo de hacerlo, ya que era para una disciplina completamente diferente. . Y esa disciplina sigue siendo muy importante. Ya sabes, las personas que están diseñando infraestructura, eso sigue siendo realmente clave. Pero ahora siento que estoy tentado. Como alguien con experiencia en desarrollo front-end, como desarrollador de JavaScript, estoy mucho más tentado a querer jugar en ese mundo, porque las herramientas se acercan más a mí.

Phil Hawksworth: Es mucho más probable que pueda usar algunas de estas cosas y entregar cosas de manera segura, en lugar de solo como un experimento propio, que es donde solía estar metido. Entonces, parece que nos estamos volviendo más poderosos como desarrolladores web, lo cual es emocionante para mí.

Vitaly: Como los Power Rangers, ¿eh?

Vitaly: Sin embargo, una cosa que sí quiero preguntarte, y esto es algo que ya discutimos, tal vez, hace una semana, pero aún quería mencionarlo, porque lo único que mencionaste en la sesión fue la noción de tener una instancia independiente de cada implementación, lo cual es realmente genial. Sin embargo, la pregunta es si tiene una tarea grande, con decenas de miles de páginas, realmente no quiere volver a implementar todo, cada vez. Entonces, esencialmente, si tienes, como, si estás usando principalmente el lado estático de las cosas. Entonces, tuvimos esta idea por un tiempo y sé que en realidad es algo que mencionaste la última vez. La idea de los despliegues atómicos.

Vitaly: donde en realidad, literalmente, se te sirvió una especie de div entre dos versiones diferentes de instantáneas de la configuración. Entonces, si dice, cambie el encabezado en todas partes, entonces, por supuesto, cada página debe volver a implementarse. Pero si cambia, tal vez, un componente, como digamos, carrusel, que tal vez afecta solo a 1000 páginas, entonces tendría sentido volver a implementar 15000 páginas. Pero solo estos 1000. Entonces, ¿podemos llegar allí? ¿Es una idea mágica lo que está ahí fuera, o es algo bastante tangible en este momento?

Phil Hawksworth: Creo que es, probablemente, el Santo Grial para los generadores de sitios estáticos y este tipo de modelo porque, sin duda, ha identificado probablemente el mayor obstáculo a superar. O el techo más grande con el que te topas. Y esos son sitios web que tienen muchas, decenas de miles o cientos de miles o millones de URL: la noción de que la construcción puede volverse muy larga. Ser capaz de detectar qué URL cambiarán, en función de un cambio de código, es un desafío. No es insuperable, pero es un gran desafío. Comprender cuál es el gráfico de dependencia en todo su sitio y luego implementarlo de manera inteligente, eso es realmente difícil de hacer.

Phil Hawksworth: Porque como mencionaste, un cambio de componente puede tener implicaciones de gran alcance, pero siempre es difícil saber cómo va a funcionar. Por lo tanto, hay una serie de generadores de sitios estáticos, los proyectos que están poniendo algo de peso detrás de ese desafío y tratando de descubrir cómo hacen la regeneración parcial y las construcciones incrementales. Estoy muy entusiasmado con la posibilidad de que eso se resuelva el día, pero por el momento, definitivamente es un gran desafío. Puede comenzar a hacer cosas como intentar compartir lógicamente su sitio y pensar, nuevamente, en algo similar al problema de la migración. Bueno, sé que esta sección es independiente en términos de algunos de los activos que usa o el tipo de contenido que vive allí, por lo que puedo implementarlos individualmente.

Phil Hawksworth: Pero eso no es ideal para mí. Ese no es realmente el escenario perfecto. Uno de los enfoques que he explorado un poco, solo como prueba de concepto, es pensar en cómo haces las cosas, como hacer un uso inteligente de los 404. Entonces, por ejemplo, un gran caso de uso para letreros muy grandes, tal vez sitios de noticias, es que cuando necesitan una URL cuando ocurre una noticia de última hora, deben ser los primeros en implementarla. Necesitan obtener una URL allí. Cosas como las noticias de la BBC, verán que la noticia llegará al sitio web y luego, con el tiempo, se agregarán gradualmente, pero llegar allí primero es clave. Entonces, tener una construcción que tome 10 minutos, 20 minutos, lo que sea que sea, eso podría ser un problema.

Phil Hawksworth: Pero, si su contenido es abstracto y tal vez solía haber sido llamado desde una API. Mencioné los sistemas de administración de contenido que son abstractos, como Contentful o Sanity, o muchos de esos. Cualquier cosa que tenga una API de contenido cambia a esa estructura de contenido que desencadenará una compilación y la ejecutaremos, pero la otra cosa que podría suceder es que, bueno, si publica su URL para eso y luego publica esa URL. , incluso si la compilación no se ejecutó, si alguien selecciona esa URL, si la primera parada en su 404 es en lugar de decir: "No lo tenemos", es en realidad para acceder a esa API directamente, entonces, puede decir , "Bueno, la compilación aún no ha terminado de llenar eso, pero puedo hacerlo en el cliente". Puedo ir directamente a la API, obtener eso, completarlo en el cliente.

Vitaly: Hmm, interesante.

Phil Hawksworth: Entonces, incluso mientras la compilación aún está en marcha, puede comenzar a completar esas cosas. Y luego, una vez finalizada la compilación, por supuesto que no llegaría a un 404. Llegaría a esa página estática. Entonces, existen técnicas y estrategias para abordarlo, pero aún así, es una respuesta muy larga y divagante, lo siento, pero mi conclusión es, sí, es un desafío. Crucemos los dedos para obtener mejores estrategias.

Vitaly: Sí, eso es genial. Entonces, me pregunto, en este punto, realmente no estamos pensando, no solo en el rendimiento en términos de entrega de contenido, sino en el rendimiento en términos de velocidad de compilación. Como el despliegue de edificios. Entonces, esto también es algo que hemos estado investigando, también desde hace bastante tiempo.

Vitaly: Una cosa más que quería preguntarte. Entonces, esto es interesante, como esta técnica que mencionaste. ¿Cómo te enteras de esto? Esto es algo que la gente tiende a publicar en sus propios blogs o, ¿es algún medio o existe un repositorio central donde puede obtener algún tipo de estudios de casos, de cómo JAMstack, cómo las empresas se movieron mientras descargaban o no se trasladaron a pila de atascos.

Phil Hawksworth: Entonces, en este momento está madurando un poco este panorama. Quiero decir, algunos de estos ejemplos, creo que estoy en una posición muy afortunada, trabajo en algún lugar en el que estoy en un papel que estoy jugando con los juguetes, encontrando formas interesantes de usarlo y comenzar a experimentar. con ellos. Entonces, estas pruebas de concepto son, en cierto modo, cosas con las que puedo experimentar y tratar de abordar estos desafíos. Pero, como mencioné anteriormente, un estudio de caso que se mostró en la conferencia JAMstack en Nueva York, y ciertamente, eventos como ese, estamos comenzando a ver las mejores prácticas o prácticas de la industria y enfoques de la industria que se hablan en ese tipo de eventos. Y ciertamente, quiero ver más y trabajar en más estudios de casos para llegar a lugares como Smashing Magazines, para que podamos compartir esta información mucho más fácilmente.

Phil Hawksworth: Creo que las grandes empresas y el espacio empresarial están adoptando JAMstack gradualmente, en diferentes lugares, de diferentes maneras, pero el mundo todavía está pendiente de salir, así que creo que cada vez que una empresa lo adopta y comparte su experiencia, todos podemos aprender de eso. Pero realmente quiero ver que se publiquen más y más de estos estudios de casos, para que podamos aprender particularmente sobre cómo se superan este tipo de desafíos.

Vitaly: Muy bien, entonces, tal vez solo la última pregunta mía, porque siempre me gusta leer preguntas. Entonces, la tierra de JAMstack, si pudiera cambiar algo, tal vez hay algo que le encantaría ver desesperadamente, más allá de las implementaciones. ¿Algo más que realmente te haga muy feliz? ¿Eso te alegraría el día? ¿Qué sería eso? ¿Qué hay en tu lista de deseos para JAMstack?

Phil Hawksworth: Qué pregunta. Quiero decir, si no hubiéramos hablado de compilaciones incrementales, eso sería...

Vitaly: Lo hicimos. Eso es demasiado tarde, ahora. Esta tarjeta ya ha sido aprobada. Necesitamos algo más.

Phil Hawksworth: Entonces...

Vitaly: Lo que quiero decir, como en una plataforma, si miras la plataforma trasera, están sucediendo tantas cosas emocionantes. Tenemos a Houdini, tenemos componentes web en camino y todo, ya que podrías estar cambiando todo el panorama de todos los componentes correctos. Por otro lado, tenemos todo este mundo mágico y elegante con SS NGS y, por supuesto, obviamente, también tenemos aplicaciones de una sola página y todo. ¿Qué es lo que más te emociona?

Phil Hawksworth: Voy a ser obtuso aquí, porque están sucediendo muchas cosas, es emocionante y hay muchas capacidades nuevas que puede usar en el navegador. Lo que realmente me emociona es que las personas muestren moderación (risas) y, como dije, respuestas aburridas, pero me encanta ver grandes ejecuciones que se realizan con moderación, de manera reflexiva, sobre la audiencia más amplia. Es realmente muy divertido y gratificante construir con la nueva biblioteca de JavaScript más brillante o la nueva API del navegador que hace, no sé, capacidades de scratch y sniff en el navegador, que necesitamos desesperadamente, en cualquier momento.

Phil Hawksworth: Pero realmente me gusta ver cosas que sé que van a funcionar en muchos, muchos lugares. Tendrán un gran rendimiento, serán comprensivos con los navegadores que existen, no solo en los escritorios de los directores ejecutivos y directores de tecnología que obtuvieron los juguetes elegantes, sino también en las personas que tienen dispositivos de mucha menor potencia, o ellos Tengo condiciones de red desafiantes y ese tipo de cosas. Me gusta ver experiencias interesantes y ricas, entregadas de una manera que simpatice con la plataforma y, en cierto modo, compasivo con la audiencia más amplia, porque creo que la web llega mucho más allá de nosotros, los desarrolladores, que creamos cosas para ella. . Y me emociona ver que se hacen cosas interesantes, de maneras que llegan a más personas.

Phil Hawksworth: Probablemente esa no sea la respuesta que necesariamente...

Vitaly: Oh, ese es un buen final. Muchas gracias. No, eso es perfecto, eso realmente lo es. ¡Muy bien, sentí que todo salió bien! ¡Muchas gracias por estar con nosotros! ¡Le voy a dar a Scott!

Phil Hawksworth: ¡Genial!

Vitaly: Solo estoy aquí para jugar preguntas y respuestas. Así que, ¡muchas gracias, Phil! Todavía estoy aquí, pero Scott, ¡el escenario es tuyo, ahora! ¿Tal vez puedas compartir con nosotros lo que viene a continuación en Smashing TV?

Scott: Lo haré, pero primero, Phil, no puedo esperar a ver cómo funciona la implementación de la API scratch-and-sniff. Suena muy interesante. Y, Vitaly, JAMstackify ya está ocupado.

Vitaly: (abatido) ¿Tomado? ¿Podemos comprarlo?

Scott: ¡No, existe!

Vitaly: Bueno, eso es demasiado tarde. Siempre llego tarde.

Phil Hawksworth: Eso es emocionante a su manera.

Vitaly: Esa es la historia de mi vida. Siempre llego tarde.

Scott: Los miembros que vienen a continuación, creo, el jueves 13, tenemos a mi viejo Zach Leatherman, hablando de lo que mejor habla, que son las fuentes. Entonces, está hablando de las cinco Y de las implementaciones de fuentes. Y luego, también me interesa mucho el que tenemos el día 19, que es la edición de video, con JavaScript y CSS, con Eva Faria. Entonces, estad atentos a ambos.

Scott: Entonces, eso es nuevamente, el próximo jueves, con Zach Leatherman, y luego el 19, con Eva, quien hablará sobre la edición de video en JavaScript y CSS. Entonces, en esa nota, Phil, ya no puedo verte, ¿sigues ahí?

Phil Hawksworth: ¡Estoy aquí!

Scott: En ese sentido, ¡muchas gracias a todos! Además, ¿hay alguien en, más o menos, cerca del área de Toronto? ¿O alguien que alguna vez haya querido visitar Toronto? Tenemos una conferencia a finales de junio y todavía quedan algunas entradas. Entonces, tal vez veamos a algunos de ustedes allí.

Vitaly: ¡Muchas gracias a todos los demás!

Vitaly: Ah, por cierto, ¡solo una cosa más! Tal vez Phil lo haya mencionado, pero también tenemos la Conferencia JAMstack en Londres, en julio. Entonces, eso también es algo a tener en cuenta. ¡Pero me despido y voy por mi ensalada! No estoy seguro de lo que...

Scott: Bien, ¡adiós a todos!

Vitaly: Muy bien, adiós a todos.

¡Eso es un envoltorio!

Agradecemos amablemente a los miembros de Smashing desde el fondo de nuestros corazones por su continuo y amable apoyo, y estamos ansiosos por organizar más seminarios web en el futuro.

Además, Phil será el maestro de ceremonias en SmashingConf Toronto 2019 la próxima semana y en JAMstack_conf. ¡Nos encantaría verte allí también!

Háganos saber si encuentra útil esta serie de entrevistas, y a quién le gustaría que entrevistáramos, o qué temas le gustaría que cubramos y nos pondremos manos a la obra.