¿Qué es el Server Side Rendering del que todos hablan? La definición sin rodeos es: Generar HTML para ser renderizado/generado desde el servidor en respuesta de una petición de un usuario desde un cliente.

Pero para entender mejor, vamos a seguir el flujo de esta petición y entender a sus actores.

A simple vista esto ya lo conoces, ¡y así es!

¿En qué momento abandonamos uno de los métodos más simplificados que tenemos para renderizar contenido, y comenzamos a construir SPA (Single Page Apps)?

El SSR genera todo el contenido en formato HTML para ser renderizada como respuesta a una petición GET del cliente.

La gran ventaja es que el contenido proveniente de alguna DB o una API y ya vendrá incluido en formato de texto.

Lo que ya no hacemos

Cuando tienes una SPA (Single Page App) el servidor se limita a entregar tu aplicación en cada petición que recibe (Entrega tu app React por ejemplo) esta, al llegar al navegador, comienza a trabajar mutando el sitio web consiguiendo datos en segundo plano con múltiples peticiones, incluso para solo dibujar la home page.

Mientras esto tiene beneficios de UX si el usuario sigue navegando el sitio (pues todo es muy rápido después) el primer render es el más lento de todos, pues se baja el app por completo, se enciende y consigue sus datos. La mayor parte de esto, en segundo plano.

Lo que preferimos

Con SSR cada petición al servidor, en vez de ser en segundo plano, se hace en primer plano y cada una de estas peticiones es tratada de forma independiente, el servidor genera la página HTML a partir del contenido en tu base de datos. Los recursos del servidor para generar estas páginas se dividirán entre el grupo de usuarios activos en el momento dado. Afortunadamente, esta generación/renderizado es lo que nuestro servidor sabe hacer mejor y no es en realidad difícil ejecutar su tarea a tiempo.

👀 ¡Ojo!, una de las ventajas más importantes para preferir SSR es que el SSR de hoy en día puede hacer uso de multiples CACHEs, esto es que puede guardar la respuesta previa a peticiones similares y así no procesar nada, solo devolver el archivo generado previamente a una misma petición. También tenemos capacidades SPA desde SSR hoy en día. 🤖

Lo más destacado

Algo que está volviendo al desarrollo web, es la generación de contenido y sitios enteros SIN JS. No es que JS sea malo, es que abusamos de él, poniendo a trabajar demasiados recursos del navegador y haciendo esperar mucho a nuestros usuarios para colocar interacciones innecesarias. Los sitios web sin JS están pensados para trabajar solo con contenido (texto) y darle una experiencia a nuestros usuarios cómoda, clásica y extremadamente rápida.

La mayor ventaja: SEO

El SEO, definitivamente.

El SSR, es la mejor manera de manipular las etiquetas meta de tu sitio web, desde el servidor. Con un control total sobre lo que se muestra, incluso de forma dinámica, colocando en nuestras etiquetas la información correcta desde el primer rénder, lo que beneficia la indexación en Google y la previsualización correcta en redes sociales.

SSR con Next.js

El framework Next.js soporta SSR, pues pre-renderiza las páginas en el servidor en cada petición (Request). Este framework nos provee de una función llamada getServerSideProps()

// ...
export async function getServerSideProps(context){
	return { props:{} }
}

El objeto context, contiene llaves con los objetos Request y Response, parámetros, queryStrings, etc. Aquí podemos conseguir datos desde la DB y colocarlos como props a nuestros componentes React.

SSR con Remix.run

El framework Remix soporta SSR entre otros. Remix va a conseguir los datos con su función loader y los pondrá a disposición del componente React gracias a un hook llamado useLoaderData, así, el desarrollador no sufre cambios en su forma típica de trabajar con React.

Esta ya es la forma estandarizada para trabajar incluso con react-router-dom, pues Remix proviene de los mismos creadores.

export async function loader({request, params}){
	return tuDB.users.findOne({_id:params.id});
}
//...
export default function Component(){
	const user = useLoaderData();
}

Depende de qué te guste más, yo me voy con Remix, pero Next es más popular.

Componentes React para servidor

React puede ser renderizado de forma isomórfica, y esa es la razón de que estos frameworks y otros puedan hacer SSR. Es decir, un componente React puede ser renderizado tanto en el navegador como en el servidor, a esto se le conoce como JavaScript Universal.

Una forma de ilustrar el Universal JS es que puedes usar las herramientas de React para devolver una respuesta con express.js que haga uso de un componente React:

app.get('/', (req,res)=>{
	const app = ReactDOMServer.renderToString(<App />);
})

Si lo anterior se combina con la herramienta: ReactDOM.hydrate(<App/>, root), es posible construir tu propio SSR con React sin usar frameworks (excepto express.js claro).

Espero hayas aprendido algo nuevo. Abrazo. Bliss.

No olvides que puedes aprender más en mi curso de Full stack.

Links relacionados

Digital Ocean tutorial