🚀😎SPA, SSR Y SSG ¿cómo, cuándo y por qué?
Tags: webdev, angular, react, javascript
Published: 2021-08-20 15:53:37

Hace unos años, basábamos el desarrollo web en frameworks puros como son **Angular, React y Vue**, todos ellos proveen lo que conocemos como client-side rendering (Single Page Application). Pero, con el paso del tiempo descubrimos diferentes necesidades a la hora de renderizar las aplicaciones es ahí donde entra lo que conocemos como SSR y SGR. ¿El problema?, muchos desarrolladores no tienen del todo claro cuando optar por alguno.

Podemos diferir que no tendría mucho sentido usar **SSR** para una TODO App así como no tendría sentido construir tu blog usando SPA, ¿o quizás si lo tendría?.

Es ahí el detalle, no existe una lista definida de cuando usar que. Sin embargo, explicaremos en que consiste cada uno, los pro y contras para que puedas tomar la mejor decisión al desarrollar tu próxima aplicación.

##Client Side Rendering##

Es la forma más común de renderizado de las herramientas más populares que tenemos actualmente como **Angular, React, Vuejs, Ember, etc**. Con esta solución, el servidor renderiza una página en blanco con una etiqueta **script** que apunta al bundle de nuestra aplicación.
Esta página en blanco es mandada al navegador del cliente, el cual empieza a correr la aplicación, compila todo lo necesario y empieza a hacer las llamadas a las respectivas Apis del proyecto.

###Pros###

- Es rápida en el servidor: ya que solo estás renderizando una página en blanco, está carga muy rápido.

- Soporta SPA: Client-Side Rendering es el único que soporta las aplicaciones SPA.

###Contras###

- No hay renderizado inicial: estás enviando una página en blanco al navegador del cliente, así que si tu aplicación es muy grande o si el visitante tiene una conexión a internet lenta, no sería muy buena idea, ¿verdad?

- Seguridad: se dice mucho que comparadas a las páginas tradicionales, las SPA son menos seguras frente a un ataque de Cross-site scripting (XSS).

- Empieza siendo un <body> vacío: esto significa que no habrá data inicial para los sistemas y scripts de SEO. Recalcar que existen herramientas en cada uno de estos frameworks basados en SPA para poder mejorar el aspecto del SEO.

##Server Side Rendering##

Se puede definir como la forma de renderizar una página web en el servidor en vez de usar el navegador. La principal diferencia con una SPA sería que cuando el usuario requiera pasar de una página a otra, deberá esperar unos segundos a que la página renderice en el servidor para luego ser enviada al browser.


###Pros###

- Contenido disponible inmediatamente: ya que estás enviando *HTML* renderizado desde el servidor, el contenido se visualizará inmediatamente.

- No hay llamadas adicionales en el cliente: lo importante de que el servidor renderice la página es que hará todas las llamadas necesarias en ese momento, en ese sentido no estarás haciendo llamadas adicionales en el lado del cliente.

- Muy bueno para el SEO: al tener acceso a la web de forma inmediata, las herramientas de SEO pueden trabajar correctamente.

###Contras###

- Lento en el servidor: recuerda que estás renderizando la página dos veces, una en el servidor y otra en el cliente. Adicional a ello, probablemente se estén llamando **APIs** para preparar toda la información. Todo esto, supone un tiempo que el cliente debe esperar. Sin embargo, si mejoras y optimizas el perfomance de tu aplicación, podrás manejarlo de mejor forma.

- Incompatible con algunas librerías: Si alguna de tus librerías depende del **document** o de **window**, tendrás que buscar la forma de reemplazarlos ya que **Node** no maneja estos elementos. Una solución ideal podrían ser las **custom NPM libraries**.


###Static Site Generation###

Se podría definir como el software que crea las páginas HTML a partir de ciertos **templates** o fuentes de información. Le puedes dar unos artículos de texto y el generador creará la web en base a ello.

###Pros###

- Alta velocidad: ya que todo el contenido puede ser generado en tiempo real, el cliente empezará a ver la información casi inmediatamente. ¿Lo mejor?, al tener esta fuente de información no tendrás que preocuparte por APIs externas.

- No hay llamadas adicionales en el lado del cliente: idealmente no tendrás que llamar APIs externas ya que al construirse la página se harán todos los llamados necesarios.

- Muy bueno para el SEO.

- Seguridad: al ser generados por documentos estáticos, la posibilidad de recibir ataques de seguridad es mínima. Esto principalmente porque este tipo de webs no manejan bases de datos.

- No hay servidor o backend como también se le conoce: al tener una fuente que produce estos templates de información, no tendrás que monitorear un servidor o ver problemas como los clásicos **memory leak**


###Contras###

- Puede llegar a ser lento: puede llegar a volverse lento dependiendo de que tanto crezca la aplicación.

- Incompatible con algunas librerías UI: por la misma razón que se comentó en las páginas SSR.


##¿Cuándo usar qué?##

Bajo mi experiencia, tomar esta decisión dependerá mucho del tipo de aplicación que se vaya a desarrollar. Por eso, lo ideal es primero tener los requerimientos exactos e incluso hasta donde podría escalar a corto y mediano plazo, para que de esa manera pueda satisfacer esas funcionalidades.

Hoy en día tenemos muchas herramientas para desarrollar software, debemos usarlas con responsabilidad y bajo un sustento técnico siempre: