React server components vs. Server side rendering en Next.js

Recientemente estuve discutiendo con unos colegas sobre los componentes del servidor y cómo esto afecta la forma en que creamos las aplicaciones utilizando React.

Next.js provee de un arsenal de opciones orientadas al servidor cómo el SSR (renderización del lado del servidor), SSG (generación de sitios estáticos) e ISR (regeneración estática incremental); Analicemos cómo encaja el RSC (React Server Components) junto con las estrategias de renderización en el servidor disponibles en Next.js.

¿Que es el SSR?

El HTML se procesa previamente de forma dinámica en el servidor y luego se envía al cliente junto con los paquetes JS y otros assets.

De esta manera, podemos presentarle al usuario al menos un sitio web no interactivo (que generalmente se parece mucho al producto final) mientras que el navegador carga, analiza y ejecuta JS faltante.

La motivación detrás de SSR debería es bastante obvia, es mejor mostrar al usuario algo “tangible” que una pantalla en blanco.

De está forma en SSR el proceso de renderizado se da en dos partes:

1. (Pre)renderizado de HTML. (lado del servidor)
2. Hidratando el HTML con JS para lograr interactividad. (lado del cliente)

¿Qué son los componentes del servidor de React (RSC)?

En React estamos familiarizados con varios tipos de componentes: componentes puros, de orden superior, controlados, etc, pero React Server Components (RSC) hace las cosas de manera un poco diferente.

RSC se refiere a componentes que operan exclusivamente en el lado del servidor, se podría decir que se parece a la renderización clásica del lado del servidor (SSR), lo cual es parcialmente acertado; Tanto React Server Components cómo SSR generan HTML en el lado del servidor, pero hay una diferencia clave:

• SSR envía HTML sin procesar, después de cargarlo en el lado del cliente, sigue el proceso de hidratación para hacer le HTML interactivo.
• RSC también transmite HTML sin formato pero sin javascript ni hidratación.

En lugar de una notación de tipo markup, el equipo de React decidió optar por una implementación personalizada en la serialización de RSC, el resultado es una notación similar a JSON que se adapta mejor para transferir componentes a través de la red.

Podríamos concluir que los componentes del servidor son más asíncronos y más granulares por lo que cuando hay una interacción de UI que requiere un componente en el lado del servidor el componente es solicitado por el cliente, compilado dinámicamente en el servidor y se transmite de vuelta al cliente como fragmentos atómicos cómo lo muestra el diagrama.

Esto da lugar para introducir el concepto de streaming, ya que los RSC han sido diseñados para funcionar con protocolos de transmisión como el HTTP/2 y server-send events.

Cuando un cliente solicita una página del servidor este comienza a procesar y envía el HTML resultante en fragmentos una vez que estén listos. En consecuencia, el cliente puede comenzar a visualizar el HTML incluso antes de que el servidor envíe la página completa.

Ahora, otra diferencia importante es la fragmentación de estos paquetes enviados al cliente, podemos decir que la granularidad de SSR es 1, ya que para una solicitud de página solo hay una respuesta que devuelve el markup generado por el servidor y así el SSR cumple su propósito.

De otra forma los RSC permiten renderizar pequeños fragmentos de la página en el servidor y transmitirlos al cliente en paquetes, lo que brinda muchos beneficios y cuantos más fragmentos decidamos diferir en el servidor más granularidad introduciremos.

Ventajas y desventajas

Los componentes del servidor React tienen muchas ventajas, pero también algunas limitaciones.

Ventajas

• Separación de responsabilidades entre la lógica del cliente y del servidor.
• El código solo del servidor reduce los tamaños del paquetes y no tiene impacto en el bundle enviado al cliente.
• Acceso directo a fuentes de datos privadas y personalizadas del lado del servidor.
• Perfecta integración con los componentes del cliente.
• Hidratación progresiva y renderizado a través de streaming.

Desventajas

• Los componentes del servidor no pueden acceder el estado, como resultado, los hooks utilizados para manejar estado como useState y useReducer, no son compatibles.
• Los Hooks para renderizar métodos de ciclo de vida como useEffect y useLayoutEffect no pueden ser utilizados por los RSC.
• Está característica se encuentra en evolución, lo que puede traer breaking changes a futuro.

¿Cuándo usar las estrategias de renderización disponibles en el framework de Next.js?

CSR

• El SEO no es importante.
• Su sitio es una aplicación compleja como “Photoshop en el navegador” o cualquier panel de administración interactivo.
• Puede diferir la primera carga, pero tenga en cuenta que la representación del lado del cliente a menudo perjudica el rendimiento y la experiencia de usuario.
• Úselo para una parte más pequeña de la página, como el cuadro de información del usuario.

SSR

• El SEO es importante
• Si debe generar la página cada vez que se realiza una solicitud, utilice SSR. Por ejemplo, cuando se requiere contenido personalizado para cada usuario o el contenido de la página cambie con frecuencia.

SSG

• El SEO es importante
• El contenido de la página es casi estático.
• Se siente cómodo con la posibilidad de un tiempo de compilación más largo o una primera solicitud retrasada para cada página: documentación.

ISG

• El SEO es importante
• Tiene contenido que cambia con poca frecuencia pero que necesita regenerarse periódicamente.

RSC

• El SEO es importante.
• La lógica de la aplicación es compleja y necesita obtener múltiples datos a través de varios recursos.

• Puede utilizar RSC para mejorar el rendimiento en dispositivos móviles para componentes React con lógica de cálculo intensivo.

• RSC permite que el servidor ejecute una lógica compleja y transmita directamente el HTML sin procesamiento resultante en el navegador.

• No se necesita interacción del lado del cliente

Conclusiones.

React Server Components mejorará en gran medida nuestro trabajo y proporcionará otra estrategia valiosa en nuestro arsenal de opciones para renderizar contenido en el servidor.

Espero que el artículo te ayudó a comprender el concepto de RSC, la idea es dar la bienvenida al futuro de la transmisión de HTML y adoptar estos nuevos paradigmas para lograr diseñar mejores experiencias de usuario.