Cach茅 vs. memoria

2/20
Recursos
Transcripci贸n

Aportes 19

Preguntas 1

Ordenar por:

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

Hilo de memes del cach茅 馃憞

Pens茅 que hab铆a un typo en Memoization y era memorization, pero no, est谩 correcta la palabra:

Memoization

Mis apuntes鈥

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 鈥渃ondicionales鈥 que el cache permite validar el 鈥渆stado鈥 de la informaci贸n

Memoization (Si se escribe as铆!!)
Guardar los c谩lculos(鈥漃eticiones鈥 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

El profe Juan usar谩 Cache

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.

Memoization no me parece recomendable con paginas que reciban datos en tiempo real

recuerden no es lo mismo Memoization que Memorization

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.

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 鈥淢emoization鈥 en funciones que no seas 鈥減uras鈥 (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鈥

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

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

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