Tipos de aplicaciones según su router: SPAs vs. SSR

Otro punto importante sobre el SSR es que este es muy importante para SEO 👀. Cuando un robot de búsqueda examina tu página y no encuentra nada de contenido (SPA) estos pueden penalizarte en SEO, algunos crawlers soportan la ejecución de código JavaScript, sí, pero aun así sigue siendo recomendado mandar un HTML con datos ya pintados 😄

Me doy una pausa en el minuto 6:32 para indicar que estoy absolutamente de acuerdo con lo que comenta Juan David. Como puede ser posible que gente que desarrolle en el frontend con JavaScript no quiera desarrollar en el backend con el mismo lenguaje de programación. Esa es la gracia de desarrollar con JavaScript!!!

24.-Tipos de aplicaciones según su router: SPAs vs. SSR

Antes de las aplicaciones web modernas se usaba el SSR “viejo” (Server Side Rendering), con el que el backend usaba una plantilla de HTML le daba a la plantilla los datos específicos requeridos en cada petición y le enviaba el HTML al navegador. Está forma de hacer render es rápida solo al principio porque el backend no le entrega al navegador la forma de interactuar con los usuarios

SPAs y CSR

Single Page Applications: Se inventa el Client Side Routing aquí gracias en parte a las API’s se empezó a renderizar el contenido desde JS directamente en el navegador. Es decir, el backend le entregaba al navegador un HTML prácticamente vacío, que tenía solo la petición de un script o alguna hoja de estilos. Entonces el navegador recibía el HTML en blanco, descargaba el JS y CSS y entonces JS podía empezar a renderizar la aplicación, entonces la carga inicial es lentísima, pero luego se hace bastante rápida, no necesita recargarse y cuando requiere información del backend solo hace la consulta a una API (que son fundamentales para estas aplicaciones).

Para trabajar de esta forma tenemos dos componentes:

Los routers son herramientas para manejar las rutas de nuestra aplicación, normalmente de eso se encargaría el servidor.

Si no se tiene control servidor se usa

• Hash Router: Con “#” definimos en que parte de la aplicación estamos (en el home, logout, clientes, admin, etc.).

Si tienes control sobre el servidor

• Browser Router: Sin importar la ruta puedes pedirle al servidor que siempre de el mismo index.html, y con JS podemos determinar en que ruta estamos y que ruta debemos mostrar dependiendo de la ruta que nos dio el servidor o navegaron e interactuaron los usuarios.

Progressive SSR

Gracias al CSR de la SPA se invento el SSR (Server Side Rendering combinado con Client Side Rendering).

En lugar de mandar un documento HTML vacío al navegador y tardara mucho en descargarlo, se podía acelerar el proceso, desde el backend enviamos al navegador una versión de la aplicación en HTML que los usuarios puedan ver mientras el navegador descarga los archivos de JS y vuelve a hacer render de la aplicación. Entonces, el backend le envía al navegador una versión de la app que solo se puede ver pero no tocar, es decir, los usuarios no pueden interactuar inmediatamente con la app.

NOTA: Para esto se necesita Node.js.

Generación de Sitios Estáticos

Estos generadores nos permiten usar el Progressive SSR mientras estamos desarrollando el sitio, pero cuando lo compilamos nos generan páginas estáticas que ya tienen cargados los datos que normalmente le pediríamos al backend y cuando hacemos deploy las aplicaciones funcionan de una. Si hay algún dato que nos daba el servidor pero que sabemos que casi no va a cambiar (como un blogpost) podemos volver a hacer deploy si queremos editar el contenido no habrá problema alguno.

Les recomiendo ver diferencias entre SSR y CSR, muy bueno para aquellos que aún no manejan del todo los temas de renderizado.

• SPA: Single Pages Aplication
• SSR: Server Side Render

Antes de las aplicaciones web se utilizaba el SSR viejo, donde se utilizaba algun lenguaje de programacion para backend. Esa forma es rapida SOLAMENTE al principio ya que no le entrega la forma de interactuar con los usuarios. El JS que podia tener solo era para animacions.

Ahora renderizamos todo con JS desde el navegador. La carga inicial es lenta ya que necesita pedir toda la informacion o los scripts, pero ya cargado todo es rapido.

Para trabajar de esta forma se usan dos ROuter, un HASH y un BROWSER. Los Routers son herramientas para manejar las rutas de nuestra aplicacion. Si queremos que nuestra aplicacion solo con un archivo HTML y todo el codigo JS que se necesita, es porque no tenemos control del servidor y necesitamos que toda la aplicacion funcione en el mismo archivo HTML. Gracias a los # sabemos en que parte de la pagina estamos.

El server Side Rendering Relodead en vez de enviar un documento HTML vacio al navegador y descargar todo, podemos desde el backend enviarle una version de la aplicacion en HTML que los usuarios puedan ver, mientras el navegador descarga los archivos de JS y vuelve al navegador.

Para esto se necesita NODEJS.

Los generaodres de sitios estaticos nos permiten hacer el SSR mientras desarrollamos el sitio, pero cuando lo compilamos nos dan paginas estaticas o SPA.

Super resumen de la clase
SSR viejo (primer server side rendering):
Antes de las apps web se aplicaba el SSR, el backend tomaba una plantilla de HTML, le daba los datos que se requerían en cada petición y lo enviaba al navegador.
El backend no le dice al navegador como interactuar con el usuario. Este solo recibe HTML con la información requerida. Cuando el usuario interactuaba se recarga la página con cada nueva información enviada desde backend.
El script contenido no se encarga de render o actualizar nuestra app, solo para cosas como animaciones o menús.
.
SPAs y CSR ( Single Page Application y Cliente Side Rendering)
Con la invención del CSR y las API empezamos a renderizar todo con el JS en el navegador. El servidor enviaba un HTML que solo incluía la petición a nuestro JS y CSS. Una vez descargado el JS, empezaba a renderizar nuestra App. Lento al inicio rápida después.
No necesita recargarse pues al necesitar información del backend lo hace con una consulta a una API. Para la navegación tenemos un hash-router y un browser-router.
No contamos con el servidor para manejar las rutas de nuestra aplicación porque todo funciona desde un mismo documento HTML. Para manejar las rutas usaremos los router.
Con el # se define en que parte de la app estamos (en el home, en el about, etc). Sin importar la ruta el servidor siempre te da el mismo HTML y con el JS mostraremos la parte de la app deseada.
.
Progressive SSR o SSR reloading.
En lugar de enviar un documento HTML vació al navegador desde el backend se va enviar al navegador una versión HTML de nuestra app que los usuarios pueden ver mientras el navegador descarga el JS y vuelva a hacer render.
Esta versión de la app se puede ver pero no tocar, los usuarios no pueden interactuar inmediatamente, como lo haría con una SPA. Pero cuando el navegador termina de descargar nuestras cosas convierte nuestra app en una SPA y los usuarios pueden interactuar a la velocidad de la luz.
Para esto se necesita node.js , resulta que la muerte de frontend developer por no querer aprender backend es muy alto.
.
Generación de sitios estáticos
Nos permite usar el SSR mientras estamos desarrollando nuestro sitio, pero compilamos en la etapa de desarrollo nos genera paginas estáticas que ya tienen cargado los datos que pediríamos al backend.
Cuando hacemos deploy las app funcionan como SPA.

Me perdí un poco en el tema de hash router y browser router y luego de buscar lo entendí de esta forma, si me equivoco diganmelo. El hash router agrega un # a la url para evitar la carga de la página, lo he visto cuanto en un articulo de blog se tiene un indice y se enlazan los titulos, al dar click hace un salto al titulo; supongo que tambien permite renderizar contenido nuevo.

Por otro lado, el browser router usa el history API para cambiar la url sin agregar el # y renderizar el contenido para esa ruta. Lo utilizan en el Taller de Creación de Router para Single Page App con JavaScript. Esta bueno para entender el proceso, aunque en proyectos reales se utiliza un framework, aca lo explica con JS vanilla.

El profe es demasiado tierno

Yo soy de los que dice que no toco backend ni loco jajajaja.

Estuvo buena ese aporte, tendré que armarme alguna ruta backend con Node js 😏

Tema un poco confuso ya que desconocia sobre CSR y SSR

Los mismos que le andan tirando hate a Juan en los comments son los frontend masters que no quieren tocar el backend para nada. 😂

Es un tema muy complejo de entender si nunca lo habiamos escuchado, por eso les recomiendo este blog del profe donde podemos tener mas claro el tema

https://platzi.com/blog/spa-vs-ssr-vs-static-site-generators/

Mis apuntes en Notion💚

!!!