Caching en Aplicaciones Web: Funciones y Niveles

Curso de Creación de APIs con Ruby on Rails

Contenido del curso

Introducción

Proyecto

Cierre

33
Creación de APIs con Rails: Buenas Prácticas y Features Avanzados
00:43 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:15

Caching en Aplicaciones Web: Funciones y Niveles

Curso de Creación de APIs con Ruby on Rails

Clase 27 de 33

Clase 27 / 33

Recursos

El caching es un pilar del rendimiento web: aplicado en el browser, en el CDN, en el servidor y dentro de la aplicación, reduce latencia, evita trabajo repetido y mejora la experiencia del usuario. Aquí verás cómo se encadenan estos niveles, qué problema resuelven y cuándo elegir memoria RAM o servicios como Redis y Memcached.

¿Qué es el caching y por qué acelera las aplicaciones web?

El caching consiste en guardar resultados ya calculados o archivos frecuentemente solicitados para responder más rápido la próxima vez. Aparece en RAM, en dispositivos móviles y en aplicaciones web. Acceder al file system o a la base de datos suele ser costoso; en cambio, servir desde memoria es mucho más veloz.

Evita leer del disco cuando el recurso ya está en memoria.
Minimiza viajes de red al reutilizar respuestas anteriores.
Reutiliza resultados calculados, como un archivo JavaScript de una single page application.

Ejemplo central: si el browser solicita un archivo JavaScript y no hay cache, el servidor debe leer del file system y devolverlo; esto es más lento que servirlo desde memoria o desde un CDN optimizado.

¿Cómo fluye una petición: browser, CDN, servidor y aplicación?

Cuando el usuario ingresa una URL, el browser realiza la petición. En producción, la primera parada suele ser un CDN. Si el CDN no lo tiene, pasa al servidor (como Apache o NGINX) que también puede cachear. Si tampoco está allí, llega a la aplicación, que puede calcular el recurso e incluso consultar la base de datos antes de responder. Luego, la respuesta se va guardando en cada nivel para acelerar las siguientes solicitudes.

¿Qué hace un CDN en el primer nivel de cache?

Distribuye assets estáticos como JavaScript, CSS y HTML.
Responde desde servidores cercanos al usuario para menor latencia.
Si hay acierto de cache, devuelve el archivo al instante.
Si hay fallo, solicita al servidor de origen y luego almacena el resultado.

¿Cómo cachea el servidor y el navegador?

Servidores como Apache o NGINX pueden tener cache interno de archivos.
El browser (Chrome, Firefox u otros) guarda en su cache lo que recibe para no pedirlo de nuevo en corto plazo.
Tras la primera respuesta completa, los niveles intermedios (navegador y CDN) sirven más rápido y evitan recalcular o releer del disco.

¿Qué pasa si nada está en cache?

El servidor llama a la aplicación.
La aplicación puede consultar la base de datos y calcular el archivo solicitado (por ejemplo, un JavaScript con datos).
La respuesta vuelve en cadena: aplicación → servidor → CDN → browser, almacenándose en cada nivel para futuras peticiones.

¿Qué tipos de cache usar: RAM, Redis o Memcached?

Dentro de la aplicación, es común guardar resultados en memoria RAM para responder más rápido que yendo al disco o a la base de datos. Para escenarios más avanzados, se emplea un cache externo como Redis o Memcached:

Mantienen los datos en memoria para acceso muy rápido.
Son servicios especializados en almacenar y devolver información con baja latencia.
Se configuran desde frameworks como Rails o desde cualquier otra aplicación del lado del servidor.

Cuándo elegir cada opción:

Cache en RAM de la aplicación: sencillo y rápido de implementar; útil para respuestas calculadas con frecuencia.
Redis o Memcached: ideal cuando varias instancias de la aplicación deben compartir cache o cuando se requieren políticas de expiración más flexibles.

Habilidades prácticas que se ponen en juego:

Comprender y configurar un CDN como primer nivel de cache.
Activar cache interno en Apache o NGINX para servir assets con rapidez.
Implementar cache en memoria RAM dentro de la aplicación para resultados calculados.
Integrar Redis o Memcached como cache externo para acelerar lecturas frente a la base de datos.
Preparar el terreno para cachear búsquedas en un API con un almacén externo.

¿Tienes dudas sobre cómo adaptar estos niveles de cache a tu proyecto o cómo configurarlos en Rails? Comparte tu caso en los comentarios y conversemos.

Resumen

¿Qué es el caching y por qué acelera las aplicaciones web?

Evita leer del disco cuando el recurso ya está en memoria.
Minimiza viajes de red al reutilizar respuestas anteriores.
Reutiliza resultados calculados, como un archivo JavaScript de una single page application.

¿Cómo fluye una petición: browser, CDN, servidor y aplicación?

¿Qué hace un CDN en el primer nivel de cache?

Distribuye assets estáticos como JavaScript, CSS y HTML.
Responde desde servidores cercanos al usuario para menor latencia.
Si hay acierto de cache, devuelve el archivo al instante.
Si hay fallo, solicita al servidor de origen y luego almacena el resultado.

¿Cómo cachea el servidor y el navegador?

Servidores como Apache o NGINX pueden tener cache interno de archivos.
El browser (Chrome, Firefox u otros) guarda en su cache lo que recibe para no pedirlo de nuevo en corto plazo.
Tras la primera respuesta completa, los niveles intermedios (navegador y CDN) sirven más rápido y evitan recalcular o releer del disco.

¿Qué pasa si nada está en cache?

El servidor llama a la aplicación.
La aplicación puede consultar la base de datos y calcular el archivo solicitado (por ejemplo, un JavaScript con datos).
La respuesta vuelve en cadena: aplicación → servidor → CDN → browser, almacenándose en cada nivel para futuras peticiones.

¿Qué tipos de cache usar: RAM, Redis o Memcached?

Mantienen los datos en memoria para acceso muy rápido.
Son servicios especializados en almacenar y devolver información con baja latencia.
Se configuran desde frameworks como Rails o desde cualquier otra aplicación del lado del servidor.

Cuándo elegir cada opción:

Cache en RAM de la aplicación: sencillo y rápido de implementar; útil para respuestas calculadas con frecuencia.
Redis o Memcached: ideal cuando varias instancias de la aplicación deben compartir cache o cuando se requieren políticas de expiración más flexibles.

Habilidades prácticas que se ponen en juego:

Comprender y configurar un CDN como primer nivel de cache.
Activar cache interno en Apache o NGINX para servir assets con rapidez.
Implementar cache en memoria RAM dentro de la aplicación para resultados calculados.
Integrar Redis o Memcached como cache externo para acelerar lecturas frente a la base de datos.
Preparar el terreno para cachear búsquedas en un API con un almacén externo.

¿Tienes dudas sobre cómo adaptar estos niveles de cache a tu proyecto o cómo configurarlos en Rails? Comparte tu caso en los comentarios y conversemos.

Comentarios (2)2 comentarios

Victor Manuel Franco Cañon

Hace 8 años

La chache en Ruby on Rails

En informática, una caché es un componente de hardware o software que almacena datos para que las solicitudes futuras de esos datos se puedan atender con mayor rapidez.

Hay dos argumentos principales para utilizar el almacenamiento en caché:

La aplicación se vuelve más rápida para el usuario. Una página web más rápida.
ayuda a tener usuarios más felices, lo que resulta en una mejor tasa de conversión.
Necesita menos hardware para el servidor web porque necesita menos
Recursos de CPU y RAM para procesar las consultas.

Algunos métodos de almacenamiento en caché:

Almacenamiento en caché de HTTP: Este es el martillo de los métodos de almacenamiento en caché y El arma de máximo rendimiento.
Almacenamiento en caché de páginas: este es el destornillador entre los métodos de almacenamiento en caché, puede sacar mucho rendimiento del sistema, pero no es tan bueno como almacenamiento en caché HTTP.
Fragmento de caché: esta es la pinza entre los métodos de caché, Pero no lo subestimes!

Conceptos extraídos de

Yively Alvarez

Hace 7 años

¿Es más eficiente utilizar $redis como DB en caché o usar los sessions en rails?

Jesús Rosas Ramírez

Hace 6 años

Obtienes un mejor desempeño usando Redis

Introducción

API de blog con Ruby on Rails y TDD

Verificar herramientas antes del proyecto Rails

Proyecto

Creación de APIs con Rails: Proyecto Blog API paso a paso

Configuración de Gemas para Pruebas en Proyectos Rails

Configuración de Gemas en Proyectos Rails: Arspec, Factory Bot y Database Cleaner

Implementación de un Health Check Endpoint en API con RSpec

Diseño de Casos de Uso y Diagramas de Entidad para Aplicaciones

Diagrama entidad relación: usuario y post

Modelado de Aplicaciones con TDD en Rails

Validaciones y Pruebas TDD en Rails: Modelos USR y Post

Implementación de Endpoints para Listar y Mostrar Posts con TDD

Implementar controlador Posts con TDD

Pruebas TDD para crear y actualizar posts

Implementación de Métodos y Manejo de Excepciones en Rails API

Active Model serializers: control total de JSON en Rails

Búsqueda y Filtrado de Posts por Título con TDD

Implementación de Búsqueda de Posts con Servicios en Rails

Problema N+1 en Rails: Detección y Solución Eficaz

Identificación y solución del problema N+1 en Rails

Flujo de Autenticación en APIs con Tokens y Proveedores

Tests con RSpec para autenticación de tokens

Autenticación con Tokens: Implementación en Rails API

Autenticación de Usuarios en Controladores Rails

Autenticación y Seguridad en CRUD de Posts en Rails

Pruebas de Creación y Actualización con Autenticación en Rails

Probando API Ruby on Rails con Postman

Caching en Aplicaciones Web: Funciones y Niveles

Aceleración de Búsquedas en Rails con Caching

Background Jobs en Rails: Conceptos y Funcionalidades

Procesamiento en Background y Envío de Correos con Rails

Envío de Correos en Rails con ActionMailer y Background Jobs

Autenticación y Autorización con JWT y Auth0 en Aplicaciones Web

Cierre

Creación de APIs con Rails: Buenas Prácticas y Features Avanzados

Caching en Aplicaciones Web: Funciones y Niveles