SSR vs. Single Page Applications

2/30
Recursos
Transcripci贸n

Aportes 44

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

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 鈥楽PA鈥欌.

TodoMachine 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)

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)

considero que es una SPA y ojala pase a ser una Progressive Server Side Rendering, con eso aprendemos lo mejor de los 2 mundos y como fusionarlo

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 = 鈥渞oot鈥 y otro con id= 鈥渕odal鈥 despu茅s crea todo contenido. entonces TodoMachine utiliza Client-side rendering

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

Estaria genial crear mas proyectos con React y no todos los cursos en base a Todo Machine

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.

Hasta este punto todoMachine es una SPA por ende usa Client siede rendering

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

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