¿Cómo optimizar una aplicación web desde el frontend?
La optimización en las aplicaciones web es un aspecto crucial para asegurar una experiencia rápida y fluida para los usuarios. Principalmente, se puede abordar desde dos frentes: el backend, donde se trabaja en la velocidad de las consultas a bases de datos y otras funcionalidades, y el frontend, donde nos enfocaremos en esta guía. Hablaremos específicamente de cómo optimizar el tiempo que se tarda en consumir una API REST y las estrategias a utilizar para mejorar el rendimiento en el frontend.
¿Podemos acelerar las solicitudes HTTP en el frontend?
Lamentablemente, desde el frontend no podemos hacer que las solicitudes HTTP sean más rápidas. Sin embargo, podemos implementar estrategias como el uso de caché y memorización para reducir la cantidad de solicitudes necesarias, aprovechando las respuestas ya obtenidas.
¿Cómo funciona el caché en el navegador?
El caché es una técnica que permite almacenar copias de respuestas HTTP para evitar realizar nuevas solicitudes si no es necesario. El navegador maneja el caché de manera predeterminada para determinar cuánto tiempo debe almacenar la información y cuándo es necesario realizar nuevamente una solicitud. Sin embargo, esto tiene sus desafíos, como saber si la información sigue actualizada o si ha cambiado desde la última vez que se almacenó.
¿Qué es la memorización en JavaScript?
La memorización es una práctica de optimización que nos permite guardar resultados de cálculos o solicitudes en estructuras de datos, como objetos o arrays, para reutilizarlos sin hacer nuevas solicitudes. Por ejemplo, en problemas como calcular la serie de Fibonacci, almacenamos resultados intermedios para no recalcular procesos repetitivos, optimizando el rendimiento de la aplicación.
// Ejemplo básico de memorización para FibonaccifunctionfibonacciMemo(n, memo ={}){if(n in memo)return memo[n];if(n <=2)return1; memo[n]=fibonacciMemo(n -1, memo)+fibonacciMemo(n -2, memo);return memo[n];}
¿Cuáles son las limitantes del caché y la memorización?
Un problema crítico es mantener la información actualizada. Si los datos cambian en el backend después de la primera solicitud, el frontend podría mostrar información obsoleta. Este riesgo varía dependiendo de la aplicación. Por ejemplo, en un banco donde las transacciones cambian continuamente, mostrar datos desactualizados podría ser desastroso.
Aparte, los datos guardados por memorización en JavaScript solamente duran hasta que la página se refresca o el navegador se cierra. Para almacenarlos más allá, se necesitaría utilizar almacenamiento local como localStorage o sessionStorage.
¿Cuál estrategia es mejor: caché o memorización?
La elección entre caché y memorización depende del tipo de proyecto y de la frecuencia con la que cambian los datos. Aplicaciones donde los datos cambian con poca frecuencia pueden beneficiarse del caché para reducir las solicitudes HTTP. Sin embargo, en aplicaciones donde los cambios son frecuentes, sería mejor evitar estas técnicas a favor de realizar solicitudes actualizadas cada vez.
Te invitamos a pensar en tu proyecto personal, como Platzi Movies con la API de The MovieDB, y reflexionar sobre qué estrategia sería más adecuada. ¿Qué ventajas o desventajas encuentras en cada enfoque? ¡Comparte tu opinión y sigue aprendiendo con nosotros en el próximo módulo!
Cache
Es la forma en la que le digamos al navegador que nos traiga la última información guardada, es decir que si necesitamos algo de información simplemente envíe lo que tiene en cache.
default
no-store
reload
no-cache
force-cache
only-if-cache
Estos son todos los “condicionales” que el cache permite validar el “estado” de la información
Memoization (Si se escribe así!!)
Guardar los cálculos(”Peticiones” que ya hicimos para no repetirlos.
En resumen es:
Crear un objeto.
Preguntar si el objeto tiene la información que necesitamos
Si sí, usar la información
Si no, hacer el fetch y guardar la información en el objeto
Consideraciones importantes.
JavaScript únicamente guarda la información en tiempo de ejecución si esta información se hace reload se va a perder.
**Para nuestro proyecto, aplicaria un poco más el cache por el tema de la cantidad de imagenes que se cargan junto con con la vista completa de la misma, todavia no entiendo muy bien pero siento que seria menor carga para el navegador, el usuario y en un caso dado para el backen
recuerden no es lo mismo ++Memoization++ que ++Memorization++
Pensé que era un typo 😬
Según Wiki si lo es 👀
Puedo decir por mi experiencia que el memorization no es el ideal a la hora de hacer una single page application, o al menos en este caso. Cuando estuve haciendo mi proyecto del curso práctico de Consumo de API REST quise utilizar memorization y me di cuenta que al recargar las páginas quedaban en blanco a no ser que estuviese en el home.
Clase 2: Caché vs. memoria
Cache
Su pronunciación en English - kaSH no le digan cache
Es la forma que el navegador que siempre nos traiga la última información del backend del API
Siempre nos dé la información que no de en cache
Propiedades
default -
no-store -
reload -
no-cache -
force-cache -
only-if-cached -
Memorization
Nosotros mismos podemos guardar las peticiones y solicitudes http para luego consumirlas.
Pasos
Crear un Objeto
Preguntar si el objeto tiene la información que necesitamos
Si la tenemos la podemos usar.
Si no está la información, hacemos el cálculo o volvemos a consumir el API
Solo se guarde hasta tiempo de compilación, ya que si recargas se vuela el cálculo o la petición
Posibles Problemas
Nosotros no sabemos si ha cambiado la información del backend.
Nosotros no sabemos si la cache o memorization está actualizada o des-actualizada.
IPA: kˈæʃ
Memoization no me parece recomendable con paginas que reciban datos en tiempo real
Sí, yo también creo que era una práctica de otros tiempos donde la red era lenta y los equipos de cómputo poco poderosos. Con redes 5G y el poder de cómputo actual no parece tan "necesario" perder 2 milisegundos en recargar datos sensibles o actuales.
¿Qué importa mas, un tuit actual que se "dibuje lento" o un tuit viejo que se "dibuje" rápido?
Quizas el problema no sea la velocidad de internet del cliente, sino la capacidad de respuesta del servidor... y por eso se necesite ahorrar peticiones si es necesario
Exactamente antes de comenzar estaba pensando repetir el curso pasado con la API de Platzi, y me surgió ésta misma pregunta: Cómo saber cuándo el backend (productos), ya no existe o ya no tiene el mismo número de productos.
Cómo reducir el tiempo de carga.
Consideraría utilizar chaché.
En las lecturas que encontré sobre este tema, leí que no es recomendable hacer “Memoization” en funciones que no seas “puras” (Functional Programming), es decir que es mejor hacerlo en funciones que siempre devuelven el mismo resultado cuando reciben el mismo argumento.
El caché puede ser buena opción porque el navegador ya trata de optimizarlo por defecto, así mientras el navegador mejora el funcionamiento de la página nosotros podemos optimizar otras partes de nuestro código, aunque también consideraría usar LocalStorage o SessionStorage…
Me encantaría echarle un ojo a esa lectura
Si no estoy mal es una lectura tuya jeje, aqui esta el link.
Corrígeme si no capte bien la idea del la lectura 😅
Yo creo que en este caso, y mientras llega el 5g, lo más factible para usar en este proyecto es caché, pero con 5g no creo que se necesite nada de eso, porque la latencia ya no va a existir
Optimización de Consumo de API REST en Frontend
La optimización en frontend no busca acelerar la red, sino evitar peticiones innecesarias mediante dos estrategias fundamentales:
1. Caché (Navegador)
Funcionamiento: Delegas al navegador la gestión de los datos. Si ya realizaste una petición, el navegador almacena la respuesta y decide si reutilizarla o hacer una nueva.
Ventaja: Los navegadores modernos gestionan automáticamente la validación de frescura de los datos.
Desafío: La complejidad de determinar si la información guardada sigue siendo válida frente a cambios en el servidor.
2. Memorización (Código JavaScript)
Funcionamiento: Guardas los resultados de las peticiones en estructuras de datos propias (objetos o arrays) dentro de tu código.
Lógica: Antes de ejecutar una petición, consultas tu objeto: si el dato existe, lo usas; si no, ejecutas la llamada y guardas el resultado.
Limitación: La información reside en memoria volátil; se pierde al recargar la página. Para persistencia, se requiere LocalStorage o SessionStorage.
Consideración Crítica: La Frescura de los Datos
El mayor riesgo de ambas estrategias es la desincronización. Si el backend cambia la información, el frontend podría seguir mostrando datos obsoletos. Evaluar si la aplicación requiere datos en tiempo real (ej. aplicaciones bancarias) es vital para decidir si es seguro implementar estas técnicas.
Comiezo de Cache
Probablemente me equivoque pero voy con todo mi dinero a que la mejor sería caché.
Diría yo que sería la mejor porque de esa forma le vamos a permitir al usuario una navegación más ágil casi siempre, mientras que con memoization solo sería más ágil mientras use el sitio, si se le va luz pues F.
.
Estoy seguro? No sé, pero voy a confiar y encomendarme a Juandc para que todo salga bien
Para la aplicación de PlatziMovies usaría la estrategia de Memoization. Considero que no pueden haber grandes cambios en una sesión, por ende con consultar al backend una sola vez bastaría.
Posible solución:
Actualmente la aplicación Platzi Movies, la carga es aceptable demora un poco en la carga de imágenes por la calidad de las mismas. El uso de cache pude ser útil para ciertas secciones en la app que no cambian como lo es la búsqueda por categoría. En la sección del código que crea las películas por ser algo que varia constantemente es mejor el uso de memorización guardando los datos en un objeto que contenga la información y le póster de las películas
En el curso de SP del profe Oscar hay una parte que se maneja el Router en un objeto esto seria una especie de Memorization ?
No exactamente. Hay muchas formas de crear tu propio router. Yo elegí hacerlo con la función de router y con hash navogation. Oscar lo hizo directamente con las rutas sin hashes. Y por cada ruta / propidad del objeto de rutas renderiza una ruta distinta. Eso también es una forma excelente de trabajar.
.
Memoization sería que todos los resultados de fetchs los guardara en un objeto y en cada consulta verificara primero si ya ese objeto de consultas (ojo, consultas, no rutas) ya tienee la información que está buscando.
Super profe ! De verdad que muchisimo más claro ! y gracias por el tiempo de responder, tengo otra pregunta ¿Por qué los comentarios o preguntas no se pueden editar ?
No me di cuenta que habia escrito mal el Memoization !!!! Perdón
Para el ejemplo de PlatziMovies lo mejor seria usar cache
El de películas usaria el de cache ya que no creo que se agregen tantas peliculas por dia, en la parte de memory la usaria para un banco ya que normalmente cuando hay una transacción y esta es realizada y aun no carga con refrescar la pagina se ve el movimiento .
No tengo experiencia con ambas tecnologías, pero según lo explicado por el profe en clase podría decir que caché sería lo ideal para evitar la pérdida de datos al recargar la página con memorization, a no ser que se use localStorage.
con la API de movieDB usaria chache porque siento que no es indispensable saber que pelicula se encuentra en tendencia en cada momento