Todo mundo esta emocionado con la idea de crear web apps o PWA o SPA. Pero la característica que tienen este tipo de apps es que tradicionalmente son apps que se renderizan en el lado del cliente ósea CSR. Esto significa que se tiene que ejecutar javascript para poder mostrar contenido al usuario. Esto implica descargar el código y pasearlo y ejecutarlo. Dependiendo de tu app esto puede ser un proceso lento o relativamente rápido. Pero un factor que afecta esto es la calidad de conexión del usuario. Si tiene una conexión lenta entonces este proceso puede sufrir bastante.

La idea detrás de SSR es optimizar la carga inicial de una app. Esto se hace por medio de la delegación de responsabilidades. En lugar de que el cliente tenga que descargar todos los recursos necesarios para mostrar la pagina, lo hace el servidor. Esto tiene varias ventajas. Primera, el servidor tiene una conexión estable y rápida. En muchas ocasiones los servidor se encuentra en el mismo data center en donde los servidores de los API de tu app se encuentran, esto hace que las peticiones de red sean mucho mas rápidas debido a que reduce el tiempo de transmisión. La otra es que en muchas ocasiones el servidor puede renderizar la pagina mas rápido que el dispositivo de un usuario. El servidor puede utilizar cache en algunos casos para optimizar el renderizado.

Cabe mencionar que no es necesario utilizar SSR en todas las apps. Es buena idea considerar por qué quieres utilizar SSR. Si tú app es una herramienta interna de trabajo probablemente no necesites utilizar SSR. Incluso si tu app ya tiene una carga eficiente sin utilizar SSR, no siempre es buena idea utilizar SSR. Al agregar SSR vas a incrementar la complejidad de la app y probablemente no tengas los resultados en optimización que estabas buscando. El tiempo de desarrollo cambiara y también cambiara la arquitectura de tu app. Uno de los problemas comunes es que el servidor no tiene acceso a los API disponibles en el navegador cosas como localStorage, indexDB, navigation, etc. Debido a esto se tiene que cambiar como carga tu app inicialmente. Para soportar estos casos probablemente necesites utilizar técnicas adicionales como lazy loading.

Tipos de SSR
Existen varios tipos de SSR vamos a hablar sobre 3 importantes dinámico, estático y cache. Cada uno de estos tipos tiene sus ventajas y es bueno evaluar cada uno en tu app para entender cual te puede funcionar mejor.

Dinamico
Se puede decir que este el el estándar en cuanto a SSR. La idea es generar la pagina en tiempo real similar a cómo lo hace el cliente pero del lado del servidor. El servidor monta y renderiza los componentes de react para obtener HTML y genera el documento que se va a mandar al cliente. Este proceso incluye hacer llamados a API, y obtener los datos necesarios para renderizar el app.

Estático
Este tipo de SSR se caracteriza por que todo el proceso de SSR sucede al momento de crear un build. En otras palabras sucede una sola vez y se reutilizan estos archivos para ser servidor al cliente. Esto funciona muy bien para apps que son principalmente estáticos como es el caso de landing pages u otros tipos de paginas que no cambian constantemente. Es especialmente util en apps o paginas donde el contenido no cambia dependiendo del usuario. La gran ventaja de utilizar este tipo de SSR es que no necesitas de un VPS para servir tu apps. Lo puedes hacer por medio de un servidor de archivos estáticos como un CDN lo cual reduce complejidad y costos. Esta opción junto con lazy loading puede ser una de las mejores combinaciones para implementar SSR. Pero es importante evaluar cada app por separado para saber si en realidad se beneficia de este tipo de SSR.

Cached SSR
Este tipo de SSR es un híbrido entre dinámico y estático. La idea principal de este SSR es que puede utilizar cache para optimizar el proceso de SSR. Puede generar un documento HTML y lo almacena en cache para que la próxima vez que un usuario lo necesite simplemente lo obtiene de cache en lugar de generarlo desde cero. Por ejemplo puede ser configurado para que cada hora se invalide el cache y se genere otra vez. Esto permitiría que se reflejen cambios a los usuarios pero a la vez se optimiza el proceso. Puede ser el caso de que el cache sea a nivel de usuario o tipo de usuario. Por ejemplo todos los usuarios con un rol, ven el mismo contenido pero usuarios con otro rol ven contenido diferente.

=====================================

Github Repo:
https://github.com/programax/reactssr