En esta sesión, repasaré estos patrones (Sharding, ISR, DPR, DSG) y mostraré a nuestros espectadores y a más de 2 millones de desarrolladores de Jamstack cómo aprovecharlos para construir sitios grandes sin la carga de tiempos de construcción prolongados.
This talk has been presented at Vue.js London Live 2021, check out the latest edition of this JavaScript Conference.
FAQ
JAMstack es una arquitectura de desarrollo web que preconstruye el sitio antes de su publicación, lo que permite que el contenido esté disponible inmediatamente cuando los usuarios acceden al sitio, eliminando los tiempos de carga y mejorando la experiencia del usuario.
Los beneficios de usar JAMstack incluyen una mayor velocidad de carga de las páginas, mejor SEO debido a la disponibilidad inmediata del contenido para los motores de búsqueda, y mayor seguridad al implementar contenido en una CDN sin tener que gestionar servidores y bases de datos directamente.
A medida que un sitio JAMstack crece, el tiempo de compilación puede aumentar significativamente debido a que cada página necesita ser pregenerada durante la construcción. Esto puede resultar en tiempos de espera prolongados antes de que el sitio pueda ser actualizado o desplegado.
Para manejar grandes sitios en JAMstack, se pueden utilizar técnicas como la compilación incremental, que permite generar solo las páginas nuevas o modificadas en lugar de reconstruir todo el sitio, y la creación de micrositios, que divide el sitio en partes más pequeñas y manejables.
La ISR permite generar solo una parte de las páginas durante la compilación inicial y generar el resto bajo demanda cuando los usuarios las soliciten. Esto reduce el tiempo de compilación inicial y mejora la capacidad de respuesta del sitio sin regenerar todo el contenido.
El renderizado persistente distribuido es una técnica que elimina la necesidad de revalidación y purga de caché con cada nueva implementación, permitiendo que el contenido crítico esté siempre disponible mientras que el contenido restante se genera bajo demanda utilizando funciones serverless.
La charla de hoy discute los patrones avanzados de renderizado de sitios en JAMstack, incluyendo los beneficios y desafíos de utilizar este enfoque. Explora soluciones como construcciones incrementales, micrositios y regeneración estática incremental para mejorar los tiempos de construcción y el rendimiento. La charla también presenta el renderizado persistente distribuido y Gatsby v4 como nuevas soluciones para mejorar la generación de sitios estáticos y el renderizado en el lado del servidor.
1. Introducción a los Patrones de Renderizado en JAMstack
Short description:
Hola. Hoy hablaré sobre los patrones avanzados de renderizado de sitios en JAMstack. Aprenderás cómo funciona el renderizado, los pros y contras de los patrones de renderizado y cómo mejorar el rendimiento. La construcción en JAMstack resuelve el problema de los tiempos de carga lentos al procesar las solicitudes en tiempo de compilación. Sin embargo, hay compensaciones a considerar.
hablaré sobre los patrones avanzados de renderizado de sitios en JAMstack. Bueno, llegaré a mi introducción en un minuto. Sí, trabajo como ingeniero de experiencia de desarrollo en Netlify y tengo un canal de YouTube donde hago tutoriales en video sobre desarrollo web. Si quieres seguirme en las redes sociales, estoy en Twitter, en Ekene underscore IO. Vamos a ello. Vale, aún no vamos a ello porque también me gustaría decirte que además de ser ingeniero de experiencia de desarrollo y hacer mi cosa en YouTube y aprender JavaScript y trabajar con él, lo que realmente quiero hacer es ser un mixólogo para poder emborrachar a todos mis amigos sin motivo alguno. Esa es probablemente una historia para otro momento. Pero eventualmente, llegaré a contar la historia. Y espero que todos estén aquí para escucharla cuando eso suceda. Pero seguiré adelante y comenzaré hoy. Entonces, lo que aprenderás hoy es cómo funciona el renderizado en JAMstack. Si has estado construyendo aplicaciones JAMstack con Knox o con cualquier otro framework, en tu generador de sitios estáticos, entenderás mejor cómo funciona el renderizado. También entenderás los pros y contras de algunos de los patrones de renderizado que tenemos, lo que aportan y las compensaciones que también tienen. Por último, también aprenderás qué hacer cuando tu sitio JAMstack tiene un rendimiento deficiente. Por ejemplo, si tarda mucho en compilarse, entenderás por qué sucede eso y las cosas que puedes hacer para acelerar ese proceso. Pero antes de sumergirnos en ello, hagamos un viaje al pasado para entender por qué esto es importante en primer lugar. Muy bien. Hasta ahora, lo que sucede es que cuando un usuario llega a tu sitio y solicita productos. Y en este caso, me refiero a cuando un usuario llega a tu sitio web y hace clic en productos, idealmente lo que sucede es que se envía una solicitud a tu servidor y dependiendo de la arquitectura de tu servidor y cómo está configurado. Esta solicitud podría pasar por tus balanceadores de carga, tus servidores web, tus servidores de aplicaciones y bases de datos y todas esas cosas que suceden detrás de escena para atender esa solicitud. Idealmente, esto se envía, tu servidor procesa la solicitud, produce el contenido correcto y lo envía de vuelta al usuario. Mientras todo eso sucede detrás de escena, por supuesto, tu usuario verá una pantalla en blanco o una pantalla de carga o un spinner, dependiendo de cómo hayas construido tu sitio. Esto no es muy bueno para el desarrollador y tampoco es muy bueno para el usuario que utiliza la aplicación porque tienen que quedarse en una pantalla en blanco o una pantalla de carga durante un tiempo antes de que se sirva el contenido real. Pero construir de la manera de JAMstack nos ayuda a resolver ese problema, y lo resuelve de esta manera, ¿verdad? Todo ese procesamiento ocurre antes de que el sitio se publique. Por ejemplo, si has construido tu aplicación JAMstack, una vez que ejecutas el comando de compilación, lo que sucede es que el generador de sitios estáticos se encarga de hacer todas las solicitudes en tu nombre, ¿verdad? Y genera todas las páginas, genera todas las rutas dinámicas y todas las partes que estarán disponibles en tu aplicación. Y luego el contenido se sirve a tus usuarios. Entonces, lo que sucede ahora es que en lugar de que los usuarios lleguen a tu sitio y hagan clic en botones para hacer solicitudes, todas esas solicitudes se realizan en tiempo de compilación para que cuando tus usuarios lleguen al sitio, todo el contenido que necesitan esté disponible de inmediato. Entonces no hay retrasos, no hay tiempo de espera, no hay giros de carga que duren para siempre. Entonces, esta es una buena manera, pero como puedes imaginar, como toda solución, como en todas partes que
2. Beneficios de JAMstack
Short description:
Los beneficios de utilizar el enfoque JAMstack incluyen una velocidad de sitio más rápida, una mejor experiencia de usuario, una mejor optimización para motores de búsqueda y una mayor seguridad mediante la implementación de CDN. Los desarrolladores pueden centrarse en sus habilidades principales sin preocuparse por la infraestructura.
La tecnología viene con una solución, también tiene algunas compensaciones. Pero antes de hablar sobre las compensaciones, los beneficios que obtenemos al utilizar el enfoque JAMstack son que tu sitio es más rápido y tus usuarios están contentos. ¿Verdad? Si nunca tienes que esperar en pantallas de carga para obtener contenido, o si visitas un sitio y ves que es rápido, si haces clic en un botón y todo sucede como debería sin retrasos, tus usuarios estarán contentos. Como usuario, yo estaría contento, ¿verdad? Y también obtienes un mejor SEO de manera predeterminada, ya que como desarrollador o propietario del sitio, todo el contenido de tu sitio está disponible de inmediato. Entonces, Google y todos los motores de búsqueda estarán contentos. Pueden rastrear e indexar tu sitio correctamente porque todo el contenido está disponible con anticipación. Y también, implementar en la CDN significa que tienes un punto de ataque limitado. Por lo tanto, es más seguro porque solo tienes que preocuparte por tu sitio y la CDN. No tienes que preocuparte por asegurar tus bases de datos, tus balanceadores de carga, tus servidores web y todas esas cosas, solo tienes que preocuparte por tu propia aplicación y la CDN se encarga del resto por ti. Construir de esta manera también permite a los desarrolladores mantenerse dentro de sus habilidades principales. Me refiero a mí mismo como un desarrollador de front-end. Me gusta construir con Vue.js y Nox.js. Nunca quiero tener que preocuparme por cómo funcionan los balanceadores de carga o los contenedores o Docker, ¿verdad? Y construir de esta manera me ayuda a mantenerme dentro de mi conjunto de habilidades y no preocuparme por esas cosas que no conozco.
3. Desafíos de construir con JAMstack
Short description:
La construcción de sitios web utilizando JAMstack puede llevar a tiempos de construcción más largos, ya que todas las páginas se generan en el momento de la construcción. Por ejemplo, si tienes un sitio con miles de productos, cada página de producto debe generarse antes de la implementación. Esto puede resultar en tiempos de espera significativos, especialmente al actualizar el sitio. Para abordar este problema, la comunidad de JAMstack ha encontrado soluciones, comenzando con la construcción incremental.
cómodo de forma predeterminada. De todos modos, eso es todo acerca de construir de esta manera. Si te sientes como estas personas que están bailando aquí, así es exactamente como me sentí cuando terminamos la plataforma JAMstack Explorer con mi equipo, lo construimos todo en la JAMstack, hicimos muchas cosas dinámicas, pero al final del día, nos divertimos y realmente no hicimos tantas cosas que nos hacen sentir incómodos como desarrolladores.
Muy bien, pero como dije, cada nueva solución introduce sus propias compensaciones. Entonces hay un poco de compensación aquí, que es que si construyes de esta manera, cuando tu sitio se vuelve grande, como puedes imaginar, ya que el proceso de construcción genera todas esas páginas de antemano, significa que si tienes muchas páginas en tu aplicación, si tienes 10,000, 100,000 páginas, todas esas páginas se generarán en el momento de la construcción, lo que significa que tendrás que esperar un poco más para que tus sitios se construyan en lugar de simplemente implementarlo tal como está. Y para que eso sea un poco más claro, imagina que tienes un sitio como este que tiene mil productos. Una vez que comienza tu proceso de construcción, todos esos productos, todos esos productos se generarán. Esto es antes de que tu sitio se implemente antes de que se publique. Entonces, el proceso de construcción lleva, veamos esto 100, 200, 300, 400. Va todo, todo el camino hasta 8,000 productos se generan, y luego, si tienes más, si tienes como 50,000, por ejemplo, tendrás que esperar todo ese tiempo para que expire antes de que se generen y se implementen todas tus páginas de productos. Entonces, por ejemplo, supongamos que tengo un sitio llamado misitio.com. En ese sitio, tengo 1,500 páginas de productos, páginas de blog y comunicados de prensa. Ahora, lo que sucede es que tengo un total de 4,000 páginas, ¿verdad? Entonces, si quiero implementar este sitio, mi proceso de construcción se activará y pregenerará todas estas páginas. Y digamos hipotéticamente, esto no es ideal de ninguna manera, pero digamos para los fines de esta presentación, que le lleva a nuestro generador de sitios estáticos un segundo construir una página. Como dije, esto no es la realidad, pero trabajemos con eso. Entonces, suponiendo que lleva un segundo construir una significa que me llevará 4,000 segundos implementar los sitios, construir el sitio antes de implementarlo. Y eso es como una hora más, ¿verdad? Entonces, imagina construir tu sitio, prepararlo, terminar, poner los toques finales y simplemente querer implementar tu sitio y tener que sentarte y esperar una hora para que se construya. Eso no es bueno. Nadie quiere eso. Y eso no es todo, ¿verdad? Si quieres actualizar el sitio, pasas por el mismo proceso exacto. En este caso, imagina que quieres agregar una página de producto más a tu sitio existente, que has construido e implementado. Lo que sucede es que tu producto va a obtener una página de producto más, ¿verdad? Entonces, en lugar de tener 1,500, tienes 1,501, lo que te da 4,001 páginas. Y lo que sucede es que, debido a que es un sitio Jamstack, el proceso de construcción se reiniciará. Y cuando eso suceda, volverá a construir todo el sitio nuevamente. Entonces, eso es otra hora más que tienes que esperar para que tu sitio se construya, solo porque actualizaste una página de producto. Eso no es ideal. No quiero eso. Estoy seguro de que tú tampoco, lo que nos lleva a las soluciones. Mientras todo esto está sucediendo, todos en la comunidad se dieron cuenta de que esto es un cuello de botella que debía solucionarse. Entonces, eso es algo bueno de la comunidad de Jamstack, todos se unen para encontrar soluciones a problemas como este que afectan a todos.
4. Compilaciones incrementales y compensaciones
Short description:
Las compilaciones incrementales te permiten regenerar solo la nueva página que agregaste a tu sitio, ahorrando tiempo durante las compilaciones posteriores. Sin embargo, no afecta la compilación inicial y rompe los conceptos de implementación atómica e inmutable.
Entonces, la primera solución es la compilación incremental. Creo que esto se originó en Gatsby hace algunos años cuando estaban buscando cómo reducir los tiempos de compilación en el Jamstack. Y solo para dejar eso muy claro, lo que hace la compilación incremental es imaginar que tienes un sitio que tiene solo siete páginas de productos. Cuando implementas el sitio, será un sitio en vivo. Las personas pueden interactuar con él, pero solo pueden ver siete productos, porque eso es lo que está disponible en tu sitio. Pero ¿qué sucede cuando actualizas ese sitio y agregas otra página de producto para tener ocho páginas? En este caso, se regenerará todo tu sitio. Y lo que eso significa es que, en lugar de construir solo una página, se construirán ocho páginas, porque se construirá incluso la que ya se había construido antes, porque por supuesto, tiene que regenerar todo el sitio. Lo que hace la compilación incremental es darte la oportunidad de construir solo la nueva página que has introducido en tu sitio y dejar las páginas anteriores como están. Esto ahorra una cantidad increíble de tiempo cuando se trata de compilaciones posteriores de tu sitio. En este caso, tenías siete páginas construidas antes, agregaste una página más, solo se genera esa nueva página, todo lo demás se mantiene como está. Entonces, al actualizar tu sitio, nunca tienes que esperar todos esos tiempos largos para reconstruir todo tu sitio. Pero, por supuesto, tiene sus compensaciones, no afecta la compilación inicial. Por ejemplo, si tuviera como 4000 páginas como en los otros ejemplos, cuando implemento ese sitio, todavía tendré que esperar ese tiempo de una hora más, tiempo hipotético para esperar a que se construya el sitio por primera vez para que no se vea afectado. Solo tiene un impacto en las compilaciones posteriores y las actualizaciones del sitio. Y también rompe los conceptos de implementación atómica e inmutable, que es algo en lo que nos enfocamos mucho en el JAMstack. Si no sabes qué es eso, pondré un enlace en la descripción en la sección de recursos para que puedas consultarlo y ver qué es eso.
5. Micrositios y Regeneración Estática Incremental
Short description:
El patrón de micrositios sugiere dividir un sitio web grande en sitios distintos para facilitar su gestión. Cada sitio se puede construir y actualizar de forma independiente sin afectar a los demás. Esto se puede lograr mediante proxies o redirecciones. Sin embargo, hay compensaciones, como redirecciones y proxies complejos, y la necesidad de gestionar varios sitios de forma individual. Otra solución es la Regeneración Estática Incremental (ISR), que te permite elegir qué páginas construir en el momento de la compilación.
se trata de eso. Muy bien, y la siguiente solución que surgió en la community son los micrositios. Este patrón literalmente dice que si tienes un gran conjunto de sitios que están juntos y tienen muchas páginas diferentes, considera dividirlos en diferentes micrositios para que sea fácil de gestionar como variaciones independientes de tu sitio en lugar de un gran conjunto que debe construirse en conjunto. Para visualizar esto, considera este globo en la pantalla ahora mismo como un sitio web grande que tiene tres secciones diferentes: productos, blog y prensa. Lo que sugiere este patrón es dividir esto en tres sitios distintos para que no estén todos juntos en un solo sitio grande que debe construirse en conjunto. La ventaja de hacerlo de esta manera es que todas las partes de tu sitio son independientes entre sí, lo que significa que si estoy construyendo mi sitio de productos, no afecta a mi blog y no afecta a mi prensa. Si estoy actualizando una página del blog, mi sitio de productos no se reconstruirá. El sitio de comunicados de prensa no se reconstruirá porque son sitios individuales e independientes que están vinculados a mi sitio principal mediante proxies y redirecciones. Y cómo funciona es imaginemos que tengo estos tres sitios divididos en diferentes sitios web desplegados. Tengo un sitio web de productos. Tengo un sitio web de blog, un sitio web de prensa, que son todos sitios individuales, independientes. Y luego llego a mi sitio.com, que es donde quiero reunirlos a los tres. Puedo usar una redirección para dirigir mi página sitio.com/productos, para que apunte a ese sitio web de productos que he construido en otro lugar. Lo mismo sucederá con el blog y la prensa. Y si no te gustan las redirecciones o prefieres usar proxies, eso también está disponible según tus preferencias y cómo quieras diseñar tu sitio.
Ah, bueno, por supuesto, tiene algunas compensaciones y advertencias. Como dije antes, tiene redirecciones y proxies complejos. Entonces, si no estás muy familiarizado con las redirecciones o cómo funcionan los proxies, esto puede no ser muy amigable para ti porque realmente necesitas entender cómo hacer eso. Para construir un micrositio, no afecta a las compilaciones iniciales. Es como el funcionamiento de las compilaciones incrementales, no tiene mucho impacto en la compilación inicial porque si estás implementando tus sitios de productos, si estás implementando tu blog, si estás implementando tu prensa, todo se implementa como sitios independientes. Pero si todavía tienes, por ejemplo, 5000 páginas de productos en el sitio, aún llevará todo ese tiempo volver a construirlo. Aunque ahora es más pequeño porque es un solo sitio en lugar de construir los tres sitios juntos. Por supuesto, tienes varios sitios que gestionar. En este caso, solo tengo tres sitios, productos, blog y prensa, pero imagina que tienes 15 sitios diferentes, secciones de tu sitio que estás construyendo de forma independiente. Significa que tienes, significa que tienes tantos sitios que debes gestionar de forma individual, lo cual puede ser difícil a veces. Esto nos lleva a la última solución, la solución de ISR. Aquí es donde las cosas comienzan a ponerse interesantes, diría yo. Regeneración estática incremental. Eso siempre es complicado de decir. ¿Por qué? Bueno, te permite elegir qué tipo de páginas, cuántas páginas quieres
6. Regeneración Estática Incremental y Advertencias
Short description:
Puedes elegir cuántas páginas generar en el momento de la compilación, sirviendo el resto bajo petición del usuario. Las páginas no pregeneradas se generan dinámicamente en segundo plano mientras se sirve una versión de respaldo. Este enfoque afecta a la compilación inicial, permitiendo una implementación más rápida. Combina la generación estática con SSR. Sin embargo, tiene compensaciones como servir contenido obsoleto durante la revalidación y comprometer las implementaciones atómicas. No es agnóstico al framework y solo está disponible para futuros desarrolladores. La última solución es el renderizado persistente distribuido.
para construir en el momento de la compilación. ¿Tiene sentido? No, te permite elegir cuántas páginas quieres generar en el momento de la compilación en lugar de generar todo por defecto, ¿verdad? Simplemente dice: `Ok, tengo 10,000 páginas, pero quiero generar solo cien de esas páginas cuando se construye mi sitio y haré el resto cuando los usuarios las soliciten. Y cómo funciona es así, este es un proceso típico de JAMstack, ¿verdad? Cuando construyes tu sitio, se generan todos los activos, todas las páginas y todas las rutas dinámicas y todo, ¿verdad? Pero lo que digo es que te daré la oportunidad de generar solo una parte de esas páginas. No tienes que hacer todo en el momento de la compilación. Puedes generar solo las que quieres que tus usuarios vean de inmediato, y luego puedes hacer el resto cuando las personas las soliciten, lo cual es genial, ¿verdad? Ahora, así es como se desarrolla. Sé que ya estás preguntando, como qué sucede cuando un usuario solicita una página que no se pregeneró en el momento de la compilación ¿verdad? Esa es una buena pregunta. Pero lo que sucede es que primero necesitas entender que cuando se genera y despliega tu sitio, todo el contenido del sitio se envía a la CDN que luego sirve a tus usuarios, ¿verdad? Ahora, cuando una página no existe en la CDN y un usuario la solicita, como en este caso, la página que he marcado con el círculo rojo lo que sucede es que esa página en particular comienza a regenerarse. Bueno, en este caso, comienza a generarse por primera vez porque no se generó antes. Y mientras eso sucede, ISR servirá una versión de respaldo de esa página a tus usuarios para que no vean una pantalla de carga o algo así. Y mientras eso sucede en segundo plano, la página se está generando. Y cuando la generación haya terminado, la página se coloca en la CDN que luego sirve a tus usuarios el contenido real. Genial. Genial. Todo bien. Antes de hablar sobre las advertencias, observa cómo tiene un gran impacto en la compilación inicial que hemos estado tratando de resolver durante un tiempo. Porque ahora tienes la oportunidad de decir: `Oh, no quiero generar cada parte de mi sitio al mismo tiempo cuando se está construyendo mi sitio, solo quiero generar el 5% de él`. Literalmente puedes decidir qué páginas quieres generar en el momento de la compilación. Tiene un gran impacto en nuestra compilación inicial porque, a diferencia de esperar a que se construyan 5,000 páginas, puedes construir 100 o 500. Y eso asegurará que tu sitio se implemente mucho más rápido que antes. También nos brinda lo mejor de ambos mundos, ¿verdad? Puedes generar estáticamente todas tus páginas, pero cuando solo solicitas contenido que no se generó en el momento de la compilación, puedes usar SSR para generar esas páginas y servirlas a los usuarios. Pero, por supuesto, también tiene sus compensaciones. Debido a que ISR utiliza la estrategia de caché de revalidación obsoleta, significa que corres el riesgo de servir contenido obsoleto a tus usuarios cuando el sitio se está revalidando. También he puesto un enlace en la sección de recursos si quieres entender mejor la revalidación obsoleta, lo pondré allí para explicarlo muy bien. También compromete las implementaciones atómicas y de grupo limitado debido a cómo afecta al contenido que se actualiza en un sitio que ya se ha implementado sin volver a implementar los sitios para purgar la caché y todo eso. Esto tampoco es agnóstico al framework. Soy un desarrollador front-end y me gusta construir con Vue y Knox. Pero esto solo está disponible para los desarrolladores del próximo año, lo que significa que realmente no me ayuda de ninguna manera. Esas son algunas advertencias.
7. Renderizado Persistente Distribuido y Gatsby v4
Short description:
El renderizado persistente distribuido elimina la necesidad de revalidación y purga completamente la caché con cada nueva implementación. El contenido crítico se genera durante el tiempo de compilación, mientras que el contenido diferido se genera bajo petición del usuario. Gatsby v4 introduce la generación estática diferida, permitiendo SSG y SSR sin comprometer los principios fundamentales. Se proporcionarán recursos adicionales para una mayor comprensión.
Veamos la última solución de la que quiero hablar hoy. Y eso es el renderizado persistente distribuido que actualmente está en beta, pero probablemente saldrá de beta pronto. Lo que hace es eliminar la necesidad de revalidación y purgar completamente la caché cuando hay una nueva implementación. De esta manera, todo el contenido que has generado está disponible para tus usuarios, se llama contenido crítico, el contenido que has diferido se generará solo cuando un usuario lo solicite. Y creo que esto utiliza funcionesserverless para generar esas páginas bajo demanda y luego ponerlas en la caché. Cuando necesitas actualizar la caché, simplemente ejecutas una nueva implementación y se purgará la caché. Y esto es intencional porque de esta manera se preservan las implementaciones atómicas e inmutables y no estamos comprometiendo ninguno de los conceptos de Jamstack que realmente nos importan. Y hemos visto esto cobrar vida con el lanzamiento de Gatsby v4, algo llamado generación estática diferida, que es un nuevo modo de renderizado que se introdujo en Gatsby 4. Y como puedes ver, está ahí fuera en el mundo, la gente lo está usando. Creo que me gusta especialmente. Actualmente estoy construyendo algo con DSG y estoy viendo cómo podemos hacer completamente SSG y SSR en sitios Jamstack sin comprometer ninguno de los principios fundamentales que realmente nos importan. La sección de recursos de la que hablé, voy a añadir todos los enlaces a las cosas de las que hablé para proporcionarte más recursos para que puedas entender algunas de estas cosas si aún no las conoces o si no estás familiarizado con ninguna de estas cosas. Y gracias a todos por tenerme aquí. Ha sido divertido. Me lo he pasado bien compartiendo estas cosas con todos. Una vez más, estoy en Twitter y en todas partes en la web en kenny underscore io y ese es mi canal de YouTube en la pantalla si quieres echar un vistazo. Gracias a todos y nos vemos la próxima vez. Adiós.
Redwood JS is a full stack React app framework that simplifies development and testing. It uses a directory structure to organize code and provides easy data fetching with cells. Redwood eliminates boilerplate and integrates Jest and Storybook. It supports pre-rendering and provides solutions for authentication and deployment. Redwood is a cross-client framework that allows for building web and mobile applications without duplicating work.
This Talk discusses the problems faced in building and rendering web applications, different rendering methods and strategies, and the benefits of the Yamstack architecture. It covers server-side rendering, static site generation, incremental static regeneration, and edge rendering. The speaker demonstrates how to build a static site using a Hello CMS and the JAMstack architecture. Other topics include connecting Storyboard with a Nuxt application, mock data, hybrid rendering, and handling I18N with a static site generator.
Sanity.io provides a content platform for structured content that replaces traditional CMS. Their solution allows businesses to structure and query content anywhere using the Sanity studio and open source React application. The talk focuses on solving the challenge of sending personalized data to users in a static website environment using Next.js Vercel for hosting and Sanity for content querying and delivery. The Sanity studio allows for modeling pages, articles, and banners, with banners being shown to visitors based on their country. The solution involves using Grok queries to fetch the right banner based on country information, demonstrating personalization based on localization and dynamic content querying.
React brought simplicity to building browser-based applications, but as new concepts like context, hooks, server components, and streaming are introduced, it's important to know the current state of the application. The JAMstack simplifies reasoning about the state of web properties through immutable assets and atomic deploys. However, as the JAMstack evolves, challenges arise in areas such as build times and API caching for large projects, especially e-commerce.
This Talk discusses API-first development with headless WordPress, highlighting its benefits and the availability of resources. It explores the use of plugins and frameworks like WPGraphQL and the headless framework from WP Engine to create custom post types and make GraphQL calls. The Talk also covers building websites, querying and caching data, deploying apps with the Atlas platform, and improving user experience. It touches on authentication, efficiency, backend resources, and WooCommerce integration in headless WordPress, as well as WordPress accessibility and SEO optimization.
Incremental static regeneration is a feature in Next.js that allows for static generation on a per-page basis without rebuilding the entire site. It helps with headless content management systems and persists between deployments. The example demonstrates how server-side rendering, static site generation, and incremental static regeneration work together. The real-time visual editor allows for immediate changes to be seen. Visit the NetJS website for an e-commerce demo and learning platform.
Curso intensivo sobre Jamstack con Next.js y Storyblok
WorkshopFree
2 authors
Es posible que ya hayas leído sobre Jamstack. Probablemente ya hayas utilizado Next.js y recientemente hayas escuchado mucho sobre los CMS sin cabeza. Este curso rápido pondrá todas las piezas juntas y te mostrará por qué Storyblok, combinado con Next.js, es la mejor combinación para tu próximo proyecto. ¡Ven y pruébalo tú mismo! - Conocimiento profundo de Jamstack. Cómo ha cambiado desde los tiempos antiguos hasta el mundo moderno. Aprende cómo se creó Jamstack comparando los sitios estáticos y los sitios dinámicos.- Cómo Next.js sirve contenido y cómo se sirve el contenido con la generación de sitios estáticos (SSG).- Metodología de diseño atómico y cómo se aplica al sistema de gestión de contenido.- Experiencia práctica en proyectos construyendo un proyecto Jamstack con Next.js y Storyblok. Requisitos previos- Cualquier editor de texto. Se recomienda Visual Studio Code- Node.js LTS- NPM o Yarn- Cuenta de GitHub- Cuenta de Vercel- Familiaridad con JavaScript, React y Git. Haber trabajado con Next.js antes es una ventaja Lo que se incluye1. Introducción y descripción general del curso2. Introducción a Jamstack3. Introducción al diseño atómico4. Descripción general de los CMS sin cabeza5. Introducción a Storyblok6. Creación de una aplicación Next.js7. Creación de un espacio Storyblok8. Conexión de Next.js y Storyblok9. Creación de componentes personalizados10. Creación de la primera página11. Introducción a Visual12. Adición de páginas dinámicas13. Creación de la sección de blogs14. Implementación en Vercel
Los frameworks de Jamstack están cambiando la forma en que construimos experiencias de primera línea en la web. Son eficientes, seguros y permiten a los desarrolladores construir aplicaciones web más rápido que antes. En esta masterclass, Nick DeJesus te guiará en la construcción de un sitio de comercio electrónico utilizando NextJS, use-shopping-cart y theme-ui. Aprenderás cómo utilizar funciones sin servidor con Netlify para realizar transacciones seguras y cómo construir componentes de interfaz de usuario accesibles que amplíen las capacidades de use-shopping-cart.
El comercio digital ha cambiado y hay una creciente demanda de soluciones más rápidas y eficientes. En esta masterclass, aprenderás sobre la evolución del comercio electrónico y cómo JAMstack y el comercio sin cabeza mejoran las experiencias de compra en la web. Exploraremos los conceptos básicos del comercio sin cabeza construyendo una página de productos mínima de comercio electrónico JAMstack con contenido estático, HTML5, CSS y Javascript. Finalmente, integraremos Commerce Layer para capacidades de comercio sin cabeza y desplegaremos nuestra aplicación en Netlify.
Comments