Published on

SPA, CSR, SSR, SSG y PWA sin complicaciones

Autores

¡Felicitaciones! Terminaste tu(s) primero(s) cursos de React, hiciste tus primeras aplicaciones, publicaste el código en GitHub, aprendiste lo fácil que es hacer deploy hacia Vercel o Netlify y ahora estas listo para el siguiente paso, quieres hacer tu propia aplicación web porque ahora con React puedes hacerlo todo!, buscas información en distintos blogs y, si no las viste antes (o lo que es más común, tienes tanta información por retener que es imposible acordarte de T O D O mientras das tus primeros pasos en React), te encuentras con siglas y nombres como SPA, SSR, CSR, SSG, PWA, NWA y dices CSM! ¿En qué momento me hablaron de esto? (Spoiler alert: posiblemente sí lo hicieron).

Entendiendo los términos

Empecemos explicando las principales características, beneficios y diferencias, para en entregas posteriores dedicar un post a cada una de ellas y quizás compartirles mi playlist para codear.

Single Page Application - SPA y el Client-Side Rendering

Una SPA es una aplicación web de una sola página en la que puedes navegar de manera dinámica sin necesidad de hacer un nuevo request al servidor para solicitarle el código HTML, CSS y JavaScript por cada ruta, evitando recargar completamente la página puesto que el código solo necesita ser descargado una vez y es ejecutado en el dispositivo del cliente (lo que es también conocido como CSR).

Características

  • Luego de una primera carga inicial donde se descarga el código de la aplicación, las navegación entre los elementos es casi instantánea puesto que utiliza JavaScript para manipular los componentes del DOM, entregarnos la nueva vista y mostrarnos la ruta actualizada.

  • Las SPA hacen uso de APIs para obtener el contenido mostrado al usuario.

Desventajas

Como toda tecnología, no es 100% aplicable a todos los casos de uso, lo cual nos presenta algunas desventajas:

  • La primera carga inicial puede llegar a ser muy pesada dependiendo del tamaño de la aplicación web.

  • Lograr un buen SEO puede llegar a ser bastante complicado; para entender mejor esto, veamos cómo ve Google nuestro index.html:

<body>
  <noscript>You need to enable JavaScript to run this app.</noscript>
  <div id="root"></div>
</body>
  • El desempeño de la aplicación depende en gran medida de la capacidad de procesamiento del dispositivo del cliente.

Ejemplos destacados: Todas nuestras aplicaciones creadas con nuestro framework favorito y el comando create-react-app y otras conocidas como Gmail donde cada interacción no requiere de una recarga completa de la página, cambiando dinámicamente las rutas de acuerdo a nuestra ubicación.


Progressive Web Apps - PWA

Las PWA son también Single Page Applications con la diferencia que deben cumplir ciertos lineamientos a fin de lograr una mayor eficiencia en el uso de recursos lo quie se traduce en tiempos de carga muy rápidos y una mejor experiencia de navegación.

Algunos beneficios que nos otorga con respecto a las SPA:

  • Si ya contamos con una aplicación web, es muy fácil volverla una PWA y ofrecer una mejor experiencia móvil a nuestros usuarios. Tampoco necesitaríamos invertir recursos en desarrollar aplicaciones nativas que requieran previamente que el usuario las descargue; nuestro canal de interacción es el navegador.

  • Funcionalidades offline, por ejemplo para consultar las últimas órdenes registradas en tu aplicación web.

Características

  • Uso de Service Workers lo que permite entre otras cosas que la aplicación funcione offline y obtener notificaciones push.

  • Están orientadas a ofrecer una experiencia similar a la de una aplicación móvil (hasta hace poco Apple limitaba la experiencia con la PWA, algo que está cambiando recientemente desde el lanzamiento de iOS 14).

  • Deben funcionar bajo HTTPS.

  • Manifiesto de Web App y PWA: se tratan de archivos JSON que contienen cierta metadata con el fin de orientar a los navegadores web sobre como mostrar nuestra aplicación.

Para más información sobre los estándares de Google que definen una buena PWA, podemos guiarnos de su checklist.

Desventajas

  • A pesar de haber mejorado el soporte, aún tenemos ciertas limitaciones en iOS, como Maximiliano Firtman (@firt) lo explica detalladamente su blog.

  • Limitaciones de acceso al hardware del dispositivo móvil.

Ejemplos destacados:


Server-Side Rendering - SSR

Tal como expliqué líneas arriba, el Client-Side Rendering funciona realizando una primera carga inicial de todos los componentes necesarios para la aplicación web para luego renderizar el contenido en el navegador del usuario mediante la manipulación del DOM. El Server-Side Rendering por otro lado funciona llevando este primer renderizado hacia el servidor el cual entrega los archivos HTML hacia el navegador, que por cierto es la manera más usada de mostrar el contenido: cada vez que visitas una página el proceso se repite, requiriendo un nuevo archivo HTML y enviándola al navegador.

Entonces ¿qué hay de interesante con esta tecnología? Que cuando hablamos de SSR con JavaScript y gracias a NodeJS estamos utilizando el mismo lenguaje en servidor y cliente lo que permite mejorar enormemente la carga iniciar de nuestras aplicaciones creadas con ReactJS.

Características

  • Al tener un HTML generado desde el servidor, es ideal para SEO puesto que Google puede indexar fácilmente nuestra información.

  • El tiempo de carga es mucho menor debido a que la carga es compartida entre el servidor y el cliente pudiendo renderizar la página inicial en el servidor y luego renderizar las páginas internas en el lado del cliente.

  • Las páginas son generadas dinámicamente, lo cual es útil para casos de uso como tiendas e-commerce o sitios de noticias donde el contenido es actualizado durante el día.

Desventajas

  • Mayor carga de trabajo en el servidor al renderizar cada nueva página solicitada.

  • Al usar un enfoque de SSR no podremos acceder a objetos window el cual no existe en el entorno de NodeJS y se accede por medio de global. Esto puede representar un problema al usar ciertas librerías, pero para ello existen alternativas específicas para SSR.

  • Es necesario un servidor para manejar las operaciones de renderizado, aunque también existe la opción de desplegar la aplicación en arquitecturas serverless por medio de funciones Lambda.

Ejemplos destacados:

Dentro del entorno de React, destaca ampliamente el framework NextJS el cual nos soluciona gran parte de los problemas iniciales con el SSR como el enrutado de páginas.


Static Site Generation - SSG

El último de estos términos que posiblemente no hayas conocido es la generación de sitios estáticos o SSG, que describe la forma en la que una aplicación genera las páginas HTML en base a la plantilla de componentes y fuentes de datos configuradas, esto se realiza durante la etapa de build o construcción de la versión del sitio para ser desplegado a producción.

Características

  • Una página estática es generada por cada vista de la aplicación lo cual es beneficioso para efectos de SEO.

  • Se pueden alojar de manera gratuita en servicios como Vercel o Netlify y existen plugins que te facilitan el despliegue hacia contenedores en Amazon S3.

  • El riesgo de ser vulnerable es mínimo: en el peor de los casos solo obtendrían acceso a tus archivos estáticos.

  • V E L O Z.

  • Frameworks ten geniales como GatsbyJS cuentan con un gran ecosistema de plugins permitiéndonos acceder a distintas fuentes de datos de manera simple y con una muy buena documentación.

Desventajas

  • El contenido se genera durante la etapa de build por lo que cada actualización en el contenido requerirá de un nuevo despliegue, lo cual en servicios de capa gratuita tiene cierto límite; esto también se vuelve un problema en sitios con contenido cambiante.

  • A esto hay que agregar que el tiempo de build incrementa en base al número de vistas: lo probé simulando un e-commerce con 400 productos (caso real donde quería aplicarlo) obteniendo unos buenos 45 segundos por build. Al tercer yarn dev dejó de ser gracioso.

  • También tenemos el mismo problema que con SSR, no podemos acceder a objetos window.

Ejemplos destacados:


Qué aprendimos de todo esto

Partiendo del supuesto que aprendiste algo, podríamos resumirlo en:

  • Existen metodologías y frameworks especializados para distintos casos de uso:

    • Si estas creando un portafolio, una página informativa o un landing page donde el SEO es de gran importancia, GatsbyJS es tu herramienta a elegir, siendo gatsby-image uno de los plugins más útiles que vas a encontrar para optimizar y convertir tus imágenes desde cualquier fuente de datos.
    • Si por otro lado te aventuras a hacer un e-commerce, sitio de noticias, blog o cualquier página que tenga contenido dinámico, NextJS es tu camino a escoger.
    • ¿Quieres crear tu propia aplicación web interna, organizador de tareas, crear un tablero de control que obtenga los datos desde distintas fuentes? Con create-react-app el mundo es tuyo.
  • Escribir un blog es difícil.

  • Llegado a este punto, ¿tiene sentido usar una base de datos MySQL, un servidor web Apache y un CMS completo basado en PHP para renderizar una landing page que podría ser generada estáticamente y ocupar en total 900kb?.