Escalamiento de Aplicaciones Web: SPA, SSR y Generadores Estáticos
Contenido del curso
Jimmy Buriticá Londoño
Juan Castro
Profesor¡El diagrama está de lujo! :kissing::ok_hand:
Christian Velázquez
Gracias.
Carlos Eduardo Gomez García
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 :D
Juan Castro
Profesor¡Muy buen punto, Retax!
En este blogpost se extiende esa información sobre SPAs y SEO: https://platzi.com/blog/una-single-page-application-no-es-tu-mejor-opcion/
Christian Velázquez
Gracias por el dato.
Iván Antonio Bustos Calderón
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!!!
Jorge De Jesus Tejeda Bello
Eso mismo digo yo, ya tienen el conocimiento de Javascript, verían lo mismo en el backend, la misma lógica que usan en el frontend es la misma que usaran en el backend
Omar Gabriel Aguilar Moscoso
si jajajaj
Juan Pablo Jimenez
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
Si tienes control sobre el servidor
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.
Juan Guillermo Perez Cardozo
hey muchas gracias por el resumen
Stanley Melgar
Les recomiendo ver diferencias entre SSR y CSR, muy bueno para aquellos que aún no manejan del todo los temas de renderizado.
José Luis Encastin Flores
¡Súper video! Se me complicó comprender el tema, pero el video está bien desarrollado. Gracias por el aporte.
Eric Concha
Gracias por el aporte. Recomendado el video como apoyo a la clase.
Joel Eduardo Sánchez Herrera
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.
Max Andy Diaz Neyra
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.
Camilo Gonzalez
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.
Max Andy Diaz Neyra
En realidad cuando le haces click al elemento de un indice y te lleva a un titulo no esta haciendo uso de routers. Ahi siplemente esta usando un elemento a cuyo atributo href apunta a un elemento cuyo atributo id tiene el mismo valor. No recuerdo ahora como escribirlo pero buscalo, que valores acepta el atributo href de la etiqueta a
Usuario anónimo
User
Natalia Ramirez Parra
El profe es demasiado tierno
Kevin Ramirez
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 😏
Víctor Isaac Arias García
Tema un poco confuso ya que desconocia sobre CSR y SSR
Kevin Acevedo
Los mismos que le andan tirando hate a Juan en los comments son los frontend masters que no quieren tocar el backend para nada. 😂
Anfernee Valera
No entendí muy bien la manera en que funciona los Generadores de Sitios Estáticos.
Juan Castro
ProfesorMira este blogpost: https://platzi.com/blog/spa-vs-ssr-vs-static-site-generators/
Rony Porraz Vargas
igual para el ssr aparte de nextjs y nuxtjs, se podria usar laravel junto con react o vue? o por ejemplo django con react o algo asi?
Carlos Eduardo Gomez García
Claro que puedes, peeeeeeeeeeeeeeeeero, tendría que ser sí o sí un consumo con API
Laravel en particular tiene Inertia que es para renderizar Vue, pero no es 100% SSR, si quisieras usar Laravel o Django con React o Vue sí o sí tendrías que consumirlos por medio de un API, y aún así usar Next o Nuxt para hacer que tu página sea SSR:(
Estuve investigando si había forma de hacerlo directamente con Laravel y Vue sin usar Nuxt pero no es posible TwT
Shelsy Angélica Garcia Laverde
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/
Jefred Bedoya
Estrategias de Renderizado y Escalabilidad
Luis Enrique Henao Rodriguez
Hola Juan David Yo soy un desarrollador BackEnd con PHP y Mysql, quiero Aprender React , hay alguna afinidad de React con este Back? ya que la empresa donde trabajo tiene su Core funcionando con PHP y la migraion a componentes de Front con React va ser extenso.. queiro por favor una guia si puedo manejar este Back con React. Gracias
Juan Castro
ProfesorEl camino más sencillo es utilizar APIs REST para consumirlas desde React.js o cualquier otro framework.
El caso de PHP es especial porque seguramente el HTML lo estabas escribiendo con PHP, así que la migración consistiría en cambiar la sintaxis de PHP por la sintaxis de JSX y obtener los datos no directamente desde el servidor, sino desde consultar una API.
Esa es la forma más fáci. Aunque también hay otras formas como renderizar un script directamente desde PHP con todas las variables que el front pueda necesitar.
Luis Enrique Henao Rodriguez
ok Gracias Juandc Estoy en la mitad del curso, de React y estoy muy intrigado para empezar a trabajar con este framework y desde la Base de datos que estamos utilizando.. un abrazo
Charles Castillo Rosas
Mis apuntes en Notion💚
Elvis Milan
!!!