SSR vs. Single Page Applications

like si lloraste con la llorona al crear TodoMachine

habla mucho, y me parecen muy largas las explicaciones, me gustaria que fuera mas al grano y conciso todo.
gracias

RESUMEN:

La representación del lado del servidor (SSR) y las aplicaciones de página única (SPA) son dos enfoques diferentes para construir aplicaciones web.

SSR es una técnica en la que el servidor genera el HTML para una página web y lo envía al navegador del cliente para ser renderizado. Esto permite que los motores de búsqueda rastreen la página web y mejora el tiempo de carga inicial para los usuarios, pero puede conducir a un rendimiento más lento y una experiencia de usuario menos dinámica.

Las SPA, por otro lado, son aplicaciones web que cargan una única página HTML y actualizan dinámicamente el contenido a medida que el usuario interactúa con la aplicación. Esto proporciona una experiencia de usuario más fluida y receptiva, pero puede dificultar que los motores de búsqueda rastreen la página web y aumentar el tiempo de carga inicial.

Tanto SSR como SPA tienen sus propias ventajas e inconvenientes, por lo que la elección entre los dos depende de los requisitos específicos del proyecto.

SPA y SSR

En la APP TODO Machine no utililzamos ninguna API, simplemente hardcodeamos la carga inicial con un patron de diseno. TODO Machine es una ‘SPA’’.

Resumen de la clase:
SSR clásico:

• Cuando haces una solicitud la recibe el backend.
• Al entrar a la URL el backend elige responder con documento HTML o JSON.
• El documento HTML tendrá todo el contenido con los datos necesarios insertados
• Para navegar utilizamos etiquetas a la cual envia una solicitud al backend a una nueva ruta.
• La nueva ruta vuelve a renderizar el HTML con todos los datos necesarios y lo envia al frontend.
• Es más rápido al inicio porque envía todo el documento listo, pero al momento de recargar la pagina el backend vuelve a generar el HTML.

SPA

• El backend responde con un HTML vacío, con petición al JS y CSS.
• EL código JS manipula el dom, hacer peticiones a APIs y renderizar el contenido.
• Al momento de navegar se hace desde el mismo HTML vacío, no importa la ruta ingresada. No tiene ahora etiquetas a, ahora escuchamos esas interacciones y se realiza consultas a una API.
• El SPA utiliza los conceptos de Client Side Rendering y Cliente Side Routing
• La primera carga es lenta porque el HTML esta vacío y es el JS quien se encargada pintarlo, pero en las siguientes recargas se hará peticiones a las APIs.

Progressive SSR

• Se envia desde el backend un documento HTML con la información necesaria.
• Cuando el usuario empieza a navegar no convierte en consultas al backend para que genera HTML, ahora actuaria como un SPA (React llama a esto hidratación)
  Progressive SSR
• Se envia desde el backend un documento HTML con la información necesaria.
• Cuando el usuario empieza a navegar no convierte en consultas al backend para que genera HTML, ahora actuaria como un SPA (React llama a esto hidratación)

TodoMachine es una SPA

Podemos desarrollar una app SSR con el framework Next.js. Con esta herramienta no necesitariamos una herramienta de navegacion porque ya la tiene integrada.

Todo Machine, no tiene contenido html en el body enviado por el servidor, y renderiza todo su contenido con javascript desde el inicio de la appliación.

Progressive Server Side Rendering … creo que deberia ser el objetivo de todo WEB PAGE

Progressive Server Side Rendering me parece la mas acertada en los proyectos, es mas compleja pero la mas optima a mi parecer para la navegacion

Todo machin es Single Page. Y ahora vamos a agregarle Router !! para crear mas rutas.

Client Side Rendering Escucha desde el cliente y solo vuelve a renderizar lo que cambio. Con este metodo podemos renderizar solo los componentes que cambiaron. Dejando cosas como el Header o Footer sin volver a recargar (salvo que reciban algun cambio)

SSR vs. Single Page Applications

.
Cualquier página web en esencia funciona de esta manera:
.

• El backend es quien recibe las solicitudes.
• El backend decide qué responder, como ser un JSON o un documento HTML.
• El frontend recibe esta respuesta del backend.

.
En el Server Side Rendering se tiene el siguiente comportamiento:
.

• Desde el backend se nos devuelve un documento HTML, con el contenido ya inyectado que necesita nuestra aplicación.
  .
• El frontend recibe este HTML.

.
Por otro lado cuando tenemos navegación el flujo es un poco distinto:
.

• Cuando se tiene navegación se hace uso de etiquetas <a>.
  .
• Estas etiquetas nos mandan hacia el backend para que este reciba esta nueva solicitud, pero ya no a la ruta /, sino a una nueva ruta.
  .
• El backend entonces vuelve a recibir esta nueva ruta por lo que vuelve a renderizar el HTML con los nuevos datos que estaba buscando el usuario.
  .
• Entonces, la primera carga es recibida por el navegador, pero cuando navegamos el backend vuelve a renderizar otro HTML completamente distinto, y por ende el navegador debe empezar a procesarlo otra vez desde cero.

.
Eso fue el proceso del SSR. Sin embargo, hay alternativas o mejor conocido como Single Page Application que consiste en:
.

• Hacer el primer rendering inicial del backend.
  .
• Pero este backend ya no nos responde con el HTML con el contenido que necesitan nuestros usuarios, sino que se puede decir que es vacío.
  .
• Es HTML vacío simplemente tiene algún div con Id root, y un script que enlaza a algún archivo con código Javascript.
  .
• Este archivo con código Javascript es quien empieza a hacer manipulación del DOM y consultas a API para traer la información y mostrárselo a los usuarios apenas pueda.
  .
• Esta comunicación es bidireccional. Es decir, ya no es simplemente el backend el que manda la información al frontend, entonces si hiciéramos navegación nuestro primer HTML ya no serviría porque el backend nos devolvería otro HTML completamente distinto. En su lugar, en las SPA siempre se tiene al mismo HTML vacío.
  .
• Entonces ya no utilizamos links normales o etiquetas <a>, sino que lo escuchamos desde Javascript con eventos que ya no nos mandan hacia otra ruta. En su lugar, estos eventos los escuchamos, procesamos y los transformamos en consultas al backend pero por medio de API REST. Los usuarios no se deben de enterar, por lo que solo notan que algo está cargando y de repente se les inserta información por medio de la manipulación del DOM.
  .
• Entonces, sin importar a qué ruta entres de la aplicación, siempre el backend te va a devolver el mismo HTML vacío. Va a ser Javascript quien escuche en qué ruta estamos, o cuál es la url, interacciones de los usuarios, que transformarán nuestra página a que muestre distinta información.

.
A esto le llamamos Client Side Rendering.
.
Las SPA solo tienen un HTML y utilizan el Client Side Routing y el Client Side Rendering también. Es decir, se renderizan y hacen la navegación desde el cliente, no desde el backend, el frontend cambia pero no hacemos nuevas consultas al backend para recibir nuevos HTML, sino que dinámicamente manipulamos ese mismo HTML que ya nos dio el backend una sola vez para todas las posibles consultas o interacciones de los usuarios.
.
Ambas tienen sus propias ventajas y desventajas. Por ejemplo el SSR:
.

• Es muy rápido cuando queremos hacer la primera carga. Porque el backend de una vez nos da el HTML listo.
  .
• Por otro lado, cuando queramos hacer cualquier tipo de navegación nos daremos cuenta que tendremos que hacer una nueva consulta al backend, este va a volver a generar ese HTML, lo va a volver a enviar al navegador para que lo vuelva a renderizar. De tal manera que tendríamos tiempo muerto, que dependiendo de la velocidad de nuestro internet podría dejar a nuestra aplicación en blanco o dejando de funcionar por cierto tiempo.

.
Con el CSR pasa exactamente lo contrario:
.

• La primera carga es demoradisima, porque el HTML que carga al principio está vacío, por lo que con Javascript tenemos que realizar peticiones al backend para poder insertar la información al HTML y que los usuarios vean algo.
  .
• Existen técnicas como el Loading Skeleton que nos permiten simular que estamos cargando información, mientras hagamos eso podemos realizar la consulta al API REST y meter el contenido que estaban buscando con manipulación del DOM.
  .
• La navegación es más rápida. Con el CSR y el Client Side Routing esto es una SPA. El primer rendering puede ser un poco más lento y el backend ya no va a tener que generar un nuevo documento HTML. Nuestra SPA lo que hace es hacer otra consulta al API REST, ese JSON lo transforma en información que podamos utilizar desde Javascript para manipular el DOM. La navegación se vuelve más rápida al utilizar el Client Side Routing.
  .
• El tiempo muerto o tiempo de carga lo seguimos controlando sin depender del internet.

.
Finalmente, podemos fusionar lo mejor de ambos SSR y SPA. Si hacemos SSR para generar desde el backend el primer documento HTML listo con la primera información que piden nuestros usuarios. Posteriormente, lo que hacemos es tomar este HTML y por medio de hidratación vamos a convertir esto en una SPA, y por medio de javascript empezamos a controlar todo, entonces transformar las interacciones de los usuarios en consultas a una API y mostrarle nuevos resultados.
.
A esto le llamamos Progressive Server Side Rendering que es la mejor estrategia que se puede usar. Sin embargo, para utilizarlo con React se requiere aplicar hidratacióm, dependiendo de cómo lo hagamos, tenemos que hacer que coincida ese documento HTML inicial con el nuevo documento HTML que renderizaríamos otra vez desde Javascript.
.
Sería posible hacerlo si utilizáramos herramienta como los React Server Components, mejorando la velocidad pero requiriendo una mayor complejidad.
.
En conclusión, todos estos son los métodos, formas, los flujos de navegación que puede seguir una aplicación. Con React utilizando React Router tenemos que saber cuál de estas estrategias estamos utilizando, dependiendo de ellas hacer un tipo de navegación u otra, los tipos de navegación dependen de qué estrategia utilicemos.
.
En este caso la aplicación TodoMachine sería una SPA puesto que todo vive en una misma vista, y al principio tenemos un solo documento HTML vacío que vamos manipulando mediante código Javascript.

Nuestra app TODO machine es un SPA pues empieza con un documento HTML vacio y es el JS quien se encarga de renderizar nuestra app.

Respondiendo a la pregunta de la clase:

To Do Machine es una SPA (Single Page Application) ya que en primera instancia recibimos un HTML vacío (#root) donde luego se renderiza y manipula el DOM según la interacción del usuario.

TodoMachine es una SPA (Single Page Application) el primer HTML que carga son 2 div uno con ID = “root” y otro con id= “modal” después crea todo contenido. entonces TodoMachine utiliza Client-side rendering

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

Actualmente es CSR ya que el back-end solo nos brinda el html básico y por medio de react creamos la aplicación. En un futuro se me ocurre que podría ser Progressive server side rendering si los todos están en una base de datos y el back nos devuelve la pagina inicial con ellos cargados, pero a medida que cargamos nuevos todos estos se procesen en el cliente.

ToDo Machine por su estructura de una sola pagina (por el momento) y al no consumir ninguna API es una SPA

El todomachine que hicimos encaja en la categoría de SPA

Estoy aquí llegandito, TodoMachine se genera en la misma página con client side rendering, pero pasarlo a progressive server side rendering no suena nada descabellado para usarla a futuro

Nuestro TODO Machine es una SPA aquí el por que!

• Las SPA son aplicaciones web que cargan una sola página HTML y actualizan dinámicamente el contenido mediante JavaScript. Si hacen una rápida comparación con la definición que les dí hace un momento y nuestro TODO podran darse cuenta que es lo mismo. Espero y les sirva!

ToDo Machine es una SPA ya que el index.html será siempre el mismo que envía el backend y una vez lo recibe el frontend, mediante código javascript se realiza la manipulación del DOM, se escuchan eventos, para renderizar los componentes adecuados de acuerdo a cada interacción del usuario.

Pues diría que To Do Machine es una single page aplication y en ese mismo diseño puede agregar las rutas.

Al inicio no hay que cargar demasidas cosas, por lo que la primera carga se mantiene rapida.

ToDo es un Server Side Rendering.
Debería ser progressive, sin embargo si nos vamos con una single page app estaría bien…

TodoMachine . com es SPA

Pienso que todoMachine esta podria estar hecho con SPA, porque como trabajaria con mucha informacion en caso de tener un backend.

Creo que TODO Machine Es una Single page aplication pero cuando ocupamos la los portales, estariamos ocupandola como Server side rendering. bueno eso creo

TodoMachine es una SPA

Es una SPA!

En este caso la todo-machine se adecua a una SPA (Single Page Application), utilizar client side rendering.
En el caso que se utilice una DataBase, entonces podría utilizarse un PSR (Progressive Server Side Rendering).

ToDo Machine es una Single Page Application (SPA)

SSR vs SPA No lo se exactamente pero debe creo que es SPA

TODO machine es una SPA, usamos client side rendering

Es una SinglePageApplication (SPA)

El SSR (server side rendering) hacemos peticiones html al servidor y nos ayudan con el SEO ya que nos cargan el contenido con un HTML de inicio, esto puede ser bueno pero al tener muchas rutas nuestra app renderizara muchas peticiones html y puede ser muy lenta de cargar todo nuevamente, por otro lado las app SPA(Single page aplication) Tardan en cargar el javascript de inicio y mostrar el contenido y una vez esto son muy rapidas con la navegación pero no prioriza el SEO, existe una forma de combinar ambas y usar Progressive Server Side Rendering.

Todo machine es SPA, porque solo una vez se trae el documento html del backend

Advanced Rendering Patterns: Lydia Hallie

todo machine es SERVER SIDE RENDERING, porque solo tine una pagina, creo yo