Video Summary and Transcription
Next.js es un marco que permite la renderización en el lado del cliente y transiciones de página fáciles. La renderización en el servidor ofrece una aplicación más segura y una mejor optimización para motores de búsqueda, pero requiere un servidor. La generación de sitios estáticos proporciona un rendimiento y escalabilidad excepcionales, pero tiene limitaciones. La regeneración estática incremental resuelve el problema de reconstruir todo el sitio web. Elegir la estrategia de renderización correcta depende del escenario específico, y para los sitios web de comercio electrónico, se recomienda la generación de sitios estáticos con regeneración estática incremental.
1. Introducción a Next.js y sus Beneficios
¡Hola a todos! Soy Michele, un arquitecto de software senior en NearForm y el autor de Real-World Next JS. NearForm es una empresa de servicios profesionales especializada en Node.js, React, Next.js, TypeScript y en el mantenimiento de paquetes de código abierto. Ahora, vamos a sumergirnos en Next.js. Es un maravilloso marco de trabajo que permite la renderización en el lado del cliente, proporcionando una experiencia similar a la de una aplicación nativa con transiciones de página fáciles y carga perezosa de componentes. Además, no requiere un servidor si no lo necesitas.
Hola a todos, y bienvenidos a mi charla, No Quieres Servir un Renderizador Fijo, Tu Próxima Aplicación JS. Antes de empezar, permítanme presentarme brevemente. Soy Michele. Trabajo como arquitecto de software senior en NearForm. Soy un experto desarrollador de Google y un MVP de Microsoft. También soy el autor de Real-World Next JS, que es un libro que, como puedes adivinar, habla sobre Next.js. Así que si después de la charla te gustaría charlar y hablar sobre Next.js, no dudes en ponerte en contacto. Estaré encantado de hablar contigo. Un par de palabras sobre NearForm. Somos una empresa de servicios profesionales, y estamos especializados en Node.js, React, Next.js, TypeScript, y lo que sea. Mantenemos muchos paquetes de código abierto que se descargan 1.2 mil millones de veces al mes en total. Así que si estás buscando un trabajo en el que puedas trabajar desde casa y estás realmente comprometido con el código abierto, no dudes en ponerte en contacto. Estaré encantado de presentarte a la empresa. Pero no estamos aquí por eso, así que hablemos de Next.js. En primer lugar, ¿qué es Next.js? ¿Por qué queremos usarlo? ¿Y por qué es tan maravilloso? Cuando React empezó a ser algo, básicamente solo teníamos la renderización en el lado del cliente. Así que esa era la norma. Básicamente generamos un gran paquete y lo servimos a través de la red. Este paquete contendrá toda la aplicación y tan pronto como se transfiera al navegador, el navegador leerá el archivo, el archivo JavaScript, lo ejecutará, y tendremos el DOM listo para ser navegado.
Así que básicamente, el problema con este enfoque, pero veremos muchos problemas más adelante, es que esto es lo que vemos cuando descargamos el paquete por primera vez. Así que mientras se está descargando, mientras se está ejecutando, vemos un spinner. Después de varios segundos, veremos la página completa lista para ser navegada. Así que este enfoque tiene algunos contras y algunos pros. Así que veamos por qué podría ser una buena o una mala elección. Así que en primer lugar, te hace sentir tu aplicación, como si fuera una aplicación nativa, y eso es porque las transiciones de página son realmente fáciles de manejar, y no tienes que refrescar la página cada vez. Cada vez que haces clic en un botón, por ejemplo, y vas a otra página, no necesitas un refresco de página. Ya tienes todos los componentes que necesitas que se cargan de forma perezosa directamente en el navegador. Así que por ejemplo, estás en la página de inicio, haces clic para leer un artículo, todo el DOM se refresca, pero la página no. Así que el DOM React intercambiará el contenido con el nuevo, y ejecutará los componentes perezosos que aún no se han ejecutado durante la primera carga. Otra gran cosa sobre la renderización en el lado del cliente es que no necesitas un servidor. Y si lo necesitas porque ya tienes uno y quieres servir tu aplicación en el lado del cliente
2. Pros y Contras de la Renderización del Lado del Servidor en React
Y no hay carga de trabajo en el servidor, lo cual es bastante bueno porque es realmente fácil de escalar. Pero si no tienes un servidor, eso sigue siendo bueno, puedes simplemente poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usando páginas de Cloudflare, o lo que sea. Y simplemente puedes alojar una aplicación completa directamente desde algo que no necesita un servidor en absoluto. Aunque esto es bueno para muchas cosas, también tiene algunos problemas, por ejemplo, con la optimización de motores de búsqueda. React no es particularmente bueno para la optimización de motores de búsqueda, especialmente en mercados fuera de Europa y América. Además, React tiene un tiempo de carga inicial de la página lento. La renderización del lado del servidor ofrece un enfoque diferente, proporcionando una aplicación más segura, compatibilidad para usuarios que no usan JavaScript y una mejor optimización de motores de búsqueda. Sin embargo, requiere un servidor y conlleva mayores costos de mantenimiento.
desde un servidor, no requiere mucho poder. Y no hay carga de trabajo en el servidor, lo cual es bastante bueno porque es realmente fácil de escalar. Pero si no tienes un servidor, eso sigue siendo bueno, puedes simplemente poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usando páginas de Cloudflare, o lo que sea. Y simplemente puedes alojar una aplicación completa directamente desde algo que no necesita un servidor en absoluto. Aunque esto es bueno para muchas cosas, también tiene algunos problemas, por ejemplo, con la optimización de motores de búsqueda. Todos sabemos que React, no es particularmente bueno para la optimización de motores de búsqueda, lo cual es cierto. Pero realmente depende del mercado que te importe. Por ejemplo, si te importa el mercado europeo y americano, sabemos que Google es el motor de búsqueda número uno y Google hoy en día es capaz de indexar contenido de React. Pero puede haber otros motores de búsqueda que son más populares en otros continentes, como Asia, por ejemplo, o África, que no leen páginas generadas por React. Así que si realmente te importan esos continentes y mercados, definitivamente deberías buscar algo diferente para construir tu aplicación.
Otro inconveniente es que React es realmente malo para el tiempo de carga inicial de la página, como vimos. Así que la primera vez que descargas un paquete, simplemente tienes que esperar varios segundos para poder navegar por él. Por eso empezamos a ver la renderización del lado del servidor como una forma diferente de abordar la renderización de React específicamente. Con la renderización del lado del servidor, esto es lo que obtienes tan pronto como solicitas una página. Puede tardar un par de segundos, porque el servidor todavía necesita renderizar la aplicación en el lado del servidor, pero eventualmente te enviará la página completa lista para navegar.
Así que este enfoque también tiene algunos pros y contras. Veamos cuáles son. Un pro, la aplicación podría ser un poco más segura. Eso es porque podrías tener cookies del lado del servidor, por ejemplo, para la autenticación, y no tienes que compartir esas cookies con el cliente, lo que hace que tu aplicación sea más segura. Puedes ocultar algunas solicitudes de servidor a servidor sin exponerlas en el cliente. Eso limita la posibilidad de un ataque de hombre en el medio, por ejemplo. Además, terminas teniendo sitios web más compatibles. Si no tienes JavaScript habilitado, todavía verás el primer renderizado de tu aplicación. La optimización de motores de búsqueda se mejora gracias a la renderización del lado del servidor, porque básicamente terminas teniendo un producto que es el mismo que podrías tener con Ruby on Rails, JavaScript Boot, Laravel, o lo que sea. El contenido puede ser altamente dinámico, y puedes tener ese tipo de dinamismo directamente en el servidor. Así, dependiendo del usuario que esté actualmente conectado, por ejemplo, podrías decidir renderizar cosas diferentes directamente en el servidor. Por supuesto, también tiene algunos problemas. Por ejemplo, se requiere un servidor. Cada solicitud se renderiza en el servidor y se transmite a los navegadores una vez renderizada. Así, habrá una mayor carga de trabajo en el servidor,
3. Generación de Sitios Estáticos y Renderización Híbrida
La generación de sitios estáticos es una tercera opción que permite una fácil escalabilidad y un rendimiento excepcional. Sirve archivos estáticos directamente al navegador, lo que lo hace seguro y elimina la necesidad de renderización del lado del servidor. Sin embargo, tiene limitaciones como la ausencia de contenido dinámico en el lado del servidor y la necesidad de reconstruir y redistribuir toda la aplicación para los cambios. React ofrece renderización híbrida, permitiendo diferentes estrategias de renderización para diferentes páginas y partes de la aplicación. La renderización del lado del cliente requiere esperar a que se ejecute el paquete de JavaScript.
mayores costos de mantenimiento, porque tendrás que mantener un servidor. Y esto es costoso. Entonces, tienes que scale el servidor horizontalmente, por ejemplo, si quieres agregar más servidores para servir tu aplicación, porque necesitas scale, o necesitas agregar más potencia al servidor que ya tienes si quieres scale verticalmente. Eso depende, por supuesto, de cómo quieras scale tus aplicaciones. Entonces, hay una tercera opción que vamos a explorar, que se llama generación de sitios estáticos. Entonces, al igual que server side rendering, esto es lo que obtienes cuando solicitas una página generada por un sitio estático. Entonces, básicamente tan pronto como haces una solicitud, no necesitas renderizarla del lado del servidor, porque ya la renderizaste durante el tiempo de construcción. Entonces, servirás tu aplicación como archivos estáticos directamente al navegador. Este enfoque tiene pros y contras, por supuesto, una ventaja es que es súper fácil de scale, y eso es porque de nuevo, no necesitas un servidor. Ya tienes activos estáticos, los pones en un CDN, en S3, en donde quieras, en un bucket, y simplemente los sirves como activos estáticos, porque no necesitas renderizar la página cada vez que recibes una solicitud. Entonces, eso lleva a rendimientos excepcionales, porque la página está lista, no necesitas renderizarla ni en el lado del cliente ni en el lado del servidor. Entonces, la página está hecha, solo tienes que transferirla. Es realmente seguro porque no tienes un servidor, así que no hay forma de atacar al servidor directamente, así que eso es otra cosa a tener en consideración. Por supuesto, de nuevo, tiene algunas contras. Veámoslos. Entonces, no se permite contenido dinámico en el lado del servidor, porque no tienes un servidor, así que no puedes renderizar cosas específicas para un usuario específico en el servidor, porque no tienes un servidor en absoluto. Se basa en la renderización del lado del cliente para todas las partes dinámicas de tu aplicación. Entonces, por ejemplo, si estás en Instagram y estás desplazándote por el feed, podrías generar la página del feed con la renderización del lado del cliente, lo siento con la generación de sitios estáticos, pero eventualmente tendrás que esperar a que el cliente entienda quién es el usuario que ha iniciado sesión y luego renderizar el contenido que es específico para ellos. Y otra cosa, que es realmente molesta, diría yo, es que si necesitas cambiar algo, por ejemplo, un error tipográfico en la página de inicio, tendrás que recargar y reconstruir y redistribuir toda la aplicación. Eso se puede solucionar con la regeneración estática incremental, pero lo veremos en detalle más adelante. Entonces, una cosa agradable acerca de React es que no tienes que comprometerte, no tienes que elegir una estrategia de renderización para todo el sitio web. Pero puedes hacer eso de manera granular en la página, cuando básicamente renderizas la página individual. Esto se llama renderización híbrida. Entonces, básicamente podrías decir, está bien, la página de inicio de este sitio web será una página generada estáticamente. Si estás en un blog, la página de publicación puede ser generada dinámicamente con la renderización del lado del servidor, por ejemplo. Eso es genial. Y algunas partes de la aplicación pueden ser renderizadas solo en el lado del cliente. Entonces, puedes elegir cuánto tiempo básicamente el usuario tiene que esperar antes de evaluar el contenido. Veamos en detalle a qué me refiero con esperar. Entonces, por ejemplo, esto es renderización del lado del cliente, ¿verdad? Hacemos una solicitud y tan pronto como hacemos la solicitud, el servidor o el CDN nos enviará una página vacía. Tan pronto como el paquete de JavaScript que contiene la aplicación React se ejecuta, comenzaremos a ver la aplicación montándose en el navegador. Entonces, como puedes ver, el servidor será realmente rápido en enviar una respuesta,
4. Regeneración Estática Incremental y Caché
Con la renderización del lado del servidor, solicitamos al servidor una página específica, esperamos a que se renderice correctamente y luego la transmitimos al cliente. La regeneración estática incremental resuelve el problema de reconstruir todo el sitio web para cada cambio. Al establecer un valor de revalidación de cinco minutos, la página se regenera para cada nueva solicitud después de ese tiempo. Si no cambia nada, se servirá la versión en caché de la página.
pero tendremos que esperar. Entonces, a medida que pasa el tiempo, tenemos que esperar a que se cargue la página. Con la renderización del lado del servidor, es un poco diferente. Pedimos al servidor una página específica. Esperamos milisegundos, esperamos, o segundos dependiendo de cuán buenos seamos escribiendo React o cuán lentas sean las APIs detrás de nuestras aplicaciones. Y luego, cuando la página se renderiza correctamente en el servidor, la transmitimos al cliente. La generación de sitios estáticos parece la combinación perfecta. Tan pronto como hacemos una solicitud, obtenemos una respuesta completa. Por eso me gusta hablar sobre la regeneración estática incremental porque básicamente resuelve un gran problema que tenemos con la generación de sitios estáticos. Entonces, no queremos reconstruir todo el sitio web cada vez que hacemos un cambio, porque esto es bueno, lo que estamos viendo ahora en la diapositiva, es bueno. Pero por ejemplo, si cambio de opinión y empiezo a amar a los setters irlandeses, por ejemplo, tendré que reconstruir todo el sitio web. Pero afortunadamente, con la regeneración estática incremental, eso no es el caso. Entonces, veamos cómo funciona. Básicamente, esta es nuestra página ahora. Esta es la página de inicio de mi sitio web, porque amo a los setters ingleses. Y digamos que tenemos un valor en nuestros getStaticProps que se llama revalidate, establecido en cinco minutos. Entonces, cada cinco minutos, tenemos que revalidar esa página, lo que significa que tenemos que reconstruirla. Entonces, publico la página. Después de un minuto, un usuario llega al sitio web y verá esa página. Después de tres minutos, otro usuario llega al sitio web y verá exactamente la misma página. Lo mismo, por supuesto, para el tercer usuario que mira nuestro sitio web después de cinco minutos. Recuerda, esto es perezoso. Entonces, si ningún usuario volverá a ver la página a partir de ahora, Next.js no recargará la aplicación en sí. No volverá a renderizar, diría yo, la página de inicio en ese caso. Pero decimos que cada cinco minutos cuando llega una nueva solicitud, tenemos que regenerar la página. Entonces, eso es básicamente lo que está sucediendo. Regeneramos la página y el próximo usuario después de cinco minutos verá una página totalmente nueva con un nuevo color de fondo con un setter irlandés en lugar de uno inglés y eso es lo que sucederá después de cuatro minutos para otro usuario y después de cinco minutos para otro usuario. Y de nuevo, a partir de ahora después de cinco minutos si otro usuario llega al sitio web tendremos que revalidar la página. Entonces, básicamente si no cambia nada veremos renderizar la página del lado del servidor. Pero pondremos algunos encabezados de caché para que sea posible que nuestra caché sirva una versión en caché de la página. Si no cambia nada, seguiremos viendo la misma página.
5. Evitando la Renderización del Lado del Servidor y Jugando Inteligente
La renderización del lado del servidor de React no es eficiente todavía. JSX requiere mucho esfuerzo del lado del servidor, lo que ralentiza el servidor y requiere escalado. Pasar a serverless resuelve el problema de escalado, pero tiene un costo. Por ejemplo, el uso de Google Cloud Functions puede costar miles de dólares al mes. Compute Engine es más barato pero todavía tiene problemas de renderización del lado del servidor. Para superar esto, es importante jugar inteligente y considerar el escenario específico.
Bueno, pero dicho esto, ¿por qué querría evitar la renderización del lado del servidor? Así que es mi opinión que la renderización del lado del servidor de React no es realmente eficiente todavía. Eso no es culpa de Next.js. Esto no es culpa de nadie sino de JSX. JSX no es realmente eficiente como un lenguaje de marcado o no sé cómo llamarlo, pero no es realmente eficiente cuando se trata de renderización del lado del servidor. Así que cada solicitud individual requiere mucho esfuerzo del lado del servidor lo que ralentiza el servidor, por lo que necesitas scale it, por lo que necesitas añadir más potencia de cálculo, más servidores para mantenerse al día con la creciente demanda de las páginas de tu aplicación. Así que podría ser fácil para un arquitecto en un cierto punto decir, sí, ve a serverless. Ya sabes que no tienes ese problema si te vas a serverless. Básicamente despliegas tu aplicación Next.js en AWS, Lambda, Google Cloud Functions, Azure Functions, lo que sea, y no necesitas scale. Eso es correcto pero ¿a qué costo? No es barato. Así que veamos un pequeño ejemplo en Google Cloud Platform. Digamos que este es el precio de Google Cloud Functions. Así que digamos que para los primeros dos millones de invocaciones por mes no pagamos nada. Más allá de dos millones pagamos 40 centavos cada millón de invocaciones. Suena barato ¿verdad? Bueno, veremos más adelante cuánto costará. Como puedes ver también pagas tiempo de computación cada 100 milisegundos. No tengo idea de cómo pronunciar esos números pequeños así que perdóname. Redes. También pagas por las redes. Así que el primer gigabyte de tráfico de transferencia es gratis luego pagas 12 centavos por gigabyte. Suena barato ¿verdad? Así que digamos que tenemos una aplicación que maneja 100 solicitudes de renderización del lado del servidor concurrent por segundo lo que lleva a 259 millones y 200,000 solicitudes por mes. ¡Es increíblemente difícil para mí como italiano decir números en inglés! ¡Lo siento mucho pero es un gran número de solicitudes verdad? El tiempo de ejecución promedio, digamos que es 300 milisegundos. Podemos usar la opción de RAM más barata que es 128 megabytes y necesitaremos alrededor de 100 kilobytes de ancho de banda por ejecución y está bien y necesitaremos más pero digamos para mantenerlo simple que esto es lo que estaremos transfiriendo. ¿Cuánto costaría? Sí, usando Google Cloud Functions por ejemplo costará tres mil dólares al mes pero se scale por supuesto se scale pero si obtienes más solicitudes el precio se hará más y más alto así que no es realmente sostenible para aplicaciones a gran escala. Si vuelves por ejemplo a Compute Engine con dos CPUs virtuales ocho gigabytes de rams pagarás como cincuenta y dos dólares al mes que es mucho más barato pero todavía tendrás el problema de la renderización del lado del servidor porque tendrás que scale it así que eventualmente querrás volver a serverless pero costará mucho así que querrás volver de nuevo a Compute Engine por ejemplo pero no scale o se volverá realmente costoso. Entonces, ¿cómo salimos de esa mala situación? Así que mi sugerencia sería jugar inteligente dependiendo del escenario. Así que empecemos con un ejemplo escenario. Digamos que queremos construir una aplicación de red social como Instagram o lo que sea así que quiero jugar un pequeño juego de preguntas contigo. Te daré un par de segundos para pensar en una respuesta así que esta es la primera pregunta. Ya hemos discutido esto veamos si estabas prestando atención. Así que digamos que tenemos que construir una característica de página de feed para nuestra aplicación por ejemplo en Instagram cuando desplazas la página de feed la página de inicio de Instagram así que el contenido es realmente dinámico y es personalizado para cada usuario no necesita SEO y eso es porque el usuario está conectado así que el feed es realmente específico para los usuarios sirve un montón de activos estáticos y es
6. Elección de Estrategias de Renderización y Seguridad
¿Qué elegirías para eso? ¿Elegirías la renderización del lado del servidor? ¿Elegirías la renderización del lado del servidor con una capa de caché? ¿Elegirías la generación de sitios estáticos y la regeneración estática incremental? ¿O elegirías la generación de sitios estáticos y la renderización del lado del cliente para mostrar contenido dinámico? En mi opinión, la respuesta correcta es la generación de sitios estáticos con la renderización del lado del cliente. Eso es porque no necesitas la renderización del lado del servidor. Así que vamos con una página de publicación única. Sirve grandes activos estáticos, fotos, videos, y hay una sola página para cada publicación. La página de configuración de la cuenta necesita alta seguridad y es un buen caso para la renderización del lado del servidor sin ninguna caché.
básicamente una gran página común para cada usuario. ¿Qué elegirías para eso? ¿Elegirías la renderización del lado del servidor? ¿Elegirías la renderización del lado del servidor con una capa de caché? ¿Elegirías la generación de sitios estáticos y la regeneración estática incremental? ¿O elegirías la generación de sitios estáticos y la renderización del lado del cliente para mostrar contenido dinámico? Pensemos en ello.
Así que en mi opinión, la respuesta correcta es la generación de sitios estáticos con la renderización del lado del cliente. Eso es porque no necesitas la renderización del lado del servidor. Sabemos que será diferente para cada usuario, pero la página es la misma. El encabezado será el mismo. El pie de página será el mismo. Sólo cambia el contenido. Así que el contenido puede ser cargado de forma perezosa en el cliente. Además, si piensas en una scale de Instagram, esto es demasiado grande para muchos de nosotros, pero realmente no quieres hacer la renderización del lado del servidor de tantas solicitudes. Se está volviendo realmente costoso. Así que vamos con una página de publicación única. Así que vemos una bonita foto. Hacemos clic en el título, y vemos la publicación completa con la descripción y los comentarios y lo que sea. Así que hay una gran cantidad de páginas. Necesitará una buena optimización de motores de búsqueda optimization porque así es como llegamos a Google con las publicaciones individuales, no con una página de inicio. Sirve grandes activos estáticos, fotos, videos, y hay una sola página para cada publicación única. ¿Qué usarías? Así que las respuestas son las mismas que la respuesta anterior pero en mi opinión este es un buen caso para la renderización del lado del servidor con caché. Déjame explicarte por qué. Estaremos haciendo la renderización del lado del servidor por primera vez y estaremos sirviendo una respuesta de caché cada vez que un nuevo usuario pida la misma publicación. Después, digamos, una hora, treinta minutos, un día, nosotros purgaremos la caché y la volveremos a renderizar, imitando cómo funciona la regeneración estática incremental. Si... está bien, veremos más adelante, con otro ejemplo, cuál podría ser una buena alternativa a eso. Pero por el momento, mantengamos nuestros pensamientos en SSR y caché. Vale, la última. La página de configuración de la cuenta necesita alta security. No necesita optimización de motores de búsqueda optimization y está protegida bajo authentication. Sabemos con seguridad que esta no es la página más visitada de cada cuenta, ¿verdad? Así que podría ser un buen caso, en mi opinión, para la renderización del lado del servidor sin ninguna caché. No queremos caché, de lo contrario el riesgo es que yo haga login y cuando otro usuario haga login verán mi cuenta. Esto no es lo que queremos, ya sabes. Pero también tenemos cookies del lado del servidor
7. Estrategias de Renderización para E-commerce
Para un sitio web de e-commerce con una página de inicio que requiere alto rendimiento, optimización de motores de búsqueda y actualizaciones de contenido ocasionales, se recomienda la generación de sitios estáticos con regeneración estática incremental. Este enfoque permite la renderización estática de la página con un rendimiento excelente y revalida la página después de un tiempo especificado. Para las páginas de productos individuales, la generación de sitios estáticos con renderización del lado del cliente es adecuada, ya que el contenido es relativamente estático y puede ser controlado en el lado del cliente utilizando llamadas a la API.
que son más seguros que las cookies del lado del cliente. Así que ese es un buen caso para la renderización del lado del servidor y podemos permitírnoslo porque no hay muchas solicitudes a esa página en particular. Así que vamos con otro ejemplo. Digamos que queremos construir un e-commerce. Entonces, la página de inicio, es realmente importante para cada e-commerce, ¿verdad? Necesitamos altos rendimientos, una increíble búsqueda de optimización de motores optimization, y el contenido cambia de vez en cuando. No muy frecuentemente, pero digamos un par de veces por semana, ¿vale? ¿Qué elegirías? Te daré un par de segundos. Mi opinión es optar por la generación de sitios estáticos y la regeneración estática incremental sin un largo tiempo de revalidación. Así que básicamente renderizas estáticamente la página, el rendimiento será increíble, y revalidarás la página después, no sé, un día, dos días, una semana. Realmente depende. Tú puedes elegir. Así que vamos con una página de producto individual. Digamos que en nuestro e-commerce, tenemos 250 productos, necesitamos un increíble SEO para cada producto, necesitamos un increíble SEO, grandes rendimientos, algunos datos dinámicos data, por ejemplo, cantidad en stock, no sé, por ejemplo, tiempo de entrega, dependiendo de dónde vengas o a dónde enviar la mercancía, etc. ¿Qué elegirías? Yo elegiría la generación de sitios estáticos y la renderización del lado del cliente. Y eso es porque la página del producto realmente no cambia mucho. De lo contrario, podríamos haber elegido la regeneración estática incremental, pero realmente no cambia mucho. Y la cantidad en stock puede ser controlada en el lado del cliente a través de llamadas a la API, por ejemplo. Y lo mismo se puede hacer con APIs externas para
8. Regeneración Estática Incremental con Fallback
Para grandes plataformas de e-commerce o blogs con mil millones de páginas, no es factible renderizar todas las páginas en tiempo de construcción. En su lugar, podemos usar la regeneración estática incremental con un fallback. Esto nos permite construir las publicaciones más populares en tiempo de construcción y diferir la renderización del resto al tiempo de solicitud. Las cabeceras de caché y la revalidación mejoran el rendimiento.
entrega. Una cosa a mencionar, y quería mencionar esto anteriormente cuando hablaba sobre la red social, pero vale la pena mencionarlo ahora, es que si tenemos un muy grande e-commerce o una plataforma de blogs, por ejemplo, donde tenemos mil millones de páginas para ser renderizadas, por supuesto no podemos renderizar mil millones de páginas en tiempo de construcción. Tomaría para siempre. Así que podríamos optar por ir con la regeneración estática incremental con un fallback. Hay un valor de fallback en la configuración de regeneración estática incremental, de modo que podemos decir, construiré, en tiempo de construcción, las cien publicaciones o artículos más populares en mi e-commerce, lo que sea, y diferiré la fase de renderización para todas las demás publicaciones o artículos en tiempo de solicitud con regeneración estática incremental. Así que básicamente generaré 100 publicaciones que son las que se buscan más y las demás serán renderizadas en tiempo de solicitud y tendremos algunas agradables cabeceras de caché gracias a la regeneración estática incremental y la revalidación por supuesto. Bueno, la última, página de configuración de cuenta, alta seguridad, no necesita optimización de motores de búsqueda optimization y está protegida bajo authentication. ¿Qué elegirías? Bueno, quería saber si estabas prestando atención esto es lo mismo que el de la red social. Ya discutimos esto así que déjame seguir adelante porque estoy a punto de terminar mi tiempo. Así que lección aprendida número uno, el contenido es dinámico y depende del usuario en ese caso, podemos generar una página estática en tiempo de construcción y renderizar los datos dinámicos data en el lado del cliente. Y eso es porque las partes dinámicas de nuestra aplicación no son significativas para la optimización de motores de búsqueda optimization, por lo que no las necesitamos. Así que es inútil para nosotros usar la renderización del lado del servidor en ese caso. Lección aprendida número dos, el contenido es estático y SEO es importante, podemos generar la página en tiempo de construcción y adoptar la regeneración estática incremental cuando sea necesario. Lección número tres, el contenido es estático pero la página se crea dinámicamente. Bueno, si el contenido es estático pero la página se crea dinámicamente, por ejemplo, estamos en un blog, publico un nuevo artículo, no quiero reconstruir todo el sitio web, ya sabes, en ese caso podríamos usar la renderización del lado del servidor y poner la web detrás de un caché o podríamos usar de nuevo, la regeneración estática incremental con un fallback de modo que generamos en tiempo de construcción todos los artículos en una plataforma de blogs, por ejemplo, que tenemos en la database y tan pronto como yo cree un nuevo artículo no necesito reconstruir todo el sitio web. Tan pronto como las solicitudes lleguen a el sitio web NetZs dirá bien tengo el fallback configurado a verdadero así que preguntaré al servidor si el artículo ahora existe. Si existe pero no lo he generado en tiempo de construcción lo generaré ahora y lo pondré detrás, detrás de la capa de caché usando cabeceras de caché. En cualquier caso, quieres evitar la renderización del lado del servidor a toda costa y eso es porque es realmente costoso. Es realmente caro de gestionar y también realmente costoso en términos de dinero porque tienes que gestionar una infraestructura, tienes que gestionar el mantenimiento de tus servidores y lo que sea. Así que es hora de usar Next.js para cómo evolucionó en lugar de por qué nació y Next.js es un increíble framework y nos permite decidir si tenemos que usar generación de sitios estáticos, regeneración estática incremental, server side rendering, renderización del lado del cliente y lo que sea. Así que por eso sigo apostando por Next.js aunque evito la renderización del lado del servidor a toda costa. Así que de nuevo, esta charla ha sido adaptada de un capítulo de Real World Next.js en caso de que estés interesado no dudes en ponerte en contacto. Muchas gracias por estar ahí y seguir la charla. Te dejaré un par de contactos en caso de que quieras ponerte en contacto. Vivo en Twitter así que si quieres ponerte en contacto ese es el mejor lugar donde puedes encontrarme. Gracias de nuevo. Espero veros a todos en persona pronto. ¡Gracias, adiós!
Comments