No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

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

24/28
Recursos

Aportes 16

Preguntas 3

Ordenar por:

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

o inicia sesi贸n.

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 鈥渧iejo鈥 (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鈥檚 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/

!!!