No querrás renderizar en el servidor tu aplicación Next.js

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

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,

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

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