Caché vs memoization en APIs REST

Curso de API REST con Javascript: Performance y Usabilidad

Contenido del curso

No sé dónde empezar

Qué se debe optimizar en el frontend (y qué no)

Optimización de imágenes

Paginación

Almacenamiento local

Bonus

Próximos pasos

20
Cierre y próximos pasos con tu portafolio
08:08 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:33

Caché vs memoization en APIs REST

Curso de API REST con Javascript: Performance y Usabilidad

Clase 2 de 20

Clase 2 / 20

Recursos

Optimizar el consumo de una API REST desde el frontend no significa hacer que internet vaya más rápido, sino evitar peticiones innecesarias. Aquí entran dos estrategias clave: caché y memoization, pensadas para quienes desarrollan aplicaciones JavaScript que dependen de datos externos.

En una aplicación web hay dos frentes de optimización. Por un lado, el backend trabaja con bases de datos, herramientas como Redis y otras técnicas que aceleran la respuesta del servidor. Por otro lado, el frontend tiene su propio terreno: decidir cuándo vale la pena hacer una solicitud HTTP y cuándo no. Y ese es justo el punto donde caché y memoization marcan la diferencia.

¿Qué es el caché del navegador y cómo ayuda a optimizar peticiones HTTP?

El caché es la forma en que le indicas al navegador cómo manejar la información que ya descargaste. Cuando usas Fetch, Axios o cualquier cliente HTTP, puedes pedirle que siempre traiga la última versión desde la API o, al contrario, que reutilice la información guardada localmente si ya la pediste antes.

¿Qué es el caché en el frontend? Es un mecanismo del navegador que guarda respuestas HTTP previas para reutilizarlas y evitar volver a pedirlas al backend. [02:15]

El problema clásico aparece con las preguntas incómodas: ¿cuánto tiempo lleva esa información ahí?, ¿sigue actualizada?, ¿hubo cambios en el backend desde entonces? Por eso existe ese meme en programación: usar caché es lo mejor y lo peor que te puede pasar. La buena noticia es que los navegadores modernos ya traen una configuración por defecto que valida estos casos por ti y funciona bien para la mayoría de escenarios.

¿Qué es la memoization en JavaScript y cuándo conviene usarla?

La memoization lleva la lógica de "no repetir trabajo" al código JavaScript. En lugar de delegarle al navegador, eres tú quien guarda los resultados en un objeto, un array o la estructura de datos que prefieras, y consulta esa estructura antes de hacer un cálculo o una petición.

El ejemplo más conocido es Fibonacci. Si calculas la secuencia de atrás hacia adelante o al revés, terminas repitiendo cálculos enormes una y otra vez. Si guardas los resultados intermedios, simplemente los lees cuando los necesitas y la aplicación deja de demorarse.

La lógica básica es así:

Creas un objeto o estructura de datos que actúe como almacén.
Antes de calcular o consumir la API, preguntas si ese dato ya está guardado.
Si está, lo usas directo y te ahorras la operación.
Si no está, haces el cálculo o la petición y guardas el resultado para la próxima.

¿Cuál es la diferencia entre caché y memoization? El caché lo gestiona el navegador a nivel de petición HTTP. La memoization la gestionas tú dentro del código JavaScript con tus propias estructuras de datos. [05:40]

¿Por qué la memoization se pierde al recargar la página?

Una consideración clave: las modificaciones que haces en JavaScript solo viven en tiempo de ejecución. En cuanto refrescas la página, cierras el navegador o apagas la computadora, esos objetos desaparecen.

Si quieres que la información memorizada sobreviva a una recarga, necesitas combinar la estrategia con almacenamiento local, usando herramientas como local storage o session storage. Sin eso, cada nueva sesión empieza desde cero.

¿Cuál es el mayor riesgo del caché y la memoization?

El problema central de ambas estrategias es el mismo: ¿cómo sabes si la información cambió en el backend después de tu primera solicitud? Si un usuario cargó datos hace un rato y vuelve a entrar, no tienes forma directa de saber si en ese lapso algo se actualizó del lado del servidor.

Hay aplicaciones donde esto no importa mucho porque la información cambia poco. Pero imagina aplicar esto a un banco: si hiciste una transacción y la app sigue mostrándote el saldo viejo porque lo tiene en caché o memorizado, el resultado sería terrible. La aplicación no se entera del cambio en el backend si no vuelve a consultarlo.

¿Cuándo no debes usar caché ni memoization? Cuando trabajas con datos críticos que cambian constantemente, como saldos bancarios, inventarios en tiempo real o transacciones financieras. [08:20]

¿Qué estrategia conviene para Platzi Movies con la API de TheMovieDB?

La decisión depende del tipo de datos que manejes. En un catálogo de películas, la información cambia con poca frecuencia, así que tanto el caché como la memoization pueden funcionar bastante bien y reducir peticiones repetidas a la API.

Algunas preguntas que te ayudan a decidir:

¿Con qué frecuencia cambian los datos en el backend?.
¿Qué tan grave sería mostrar información desactualizada?.
¿Necesitas que la optimización sobreviva a una recarga de página?.
¿Prefieres delegar la lógica al navegador o controlarla desde tu código?.

Cuéntame en los comentarios cuál estrategia usarías para Platzi Movies con la API de TheMovieDB, qué ventajas y desventajas le ves a cada una, o si prefieres dejar el funcionamiento por defecto sin aplicar ninguna optimización.