Si has seguido el viaje de DEV y su proyecto open source Forem, sabes que siempre han estado obsesionados con el rendimiento web. Desde el principio, su filosofía ha sido simple: mantener la arquitectura lo más liviana posible, cachear agresivamente en el edge, y dejar que el monolito Rails (Forem) se enfoque en lo que mejor sabe hacer.

Durante años, Fastly manejó su cacheo de HTML en el edge de forma brillante — la mayoría de las solicitudes de páginas nunca tocaban sus servidores Puma, manteniendo el uso de RAM bajo y los tiempos de respuesta en milisegundos.

Pero cachear HTML estático es un problema bien conocido. Las imágenes subidas por usuarios son una bestia completamente diferente.

“A medida que DEV crecía, nos encontramos ahogados en imágenes. Cada portada, avatar, captura de comentario y banner de desafío es un asset de alta resolución subido por nuestra comunidad.”

Servir miles de millones de imágenes globalmente, mientras se mantienen livianos los tamaños de página, los llevó a una trampa de escalabilidad silenciosa: un pipeline de medios multi-CDN enredado, tarifas masivas de egress en la nube, y facturas mensuales que dolían a la vista.

Esta es la historia de cómo terminaron con el caos multi-CDN, simplificaron su arquitectura de medios, ahorraron una fortuna, y usaron edge scripting para construir un pipeline de imágenes más inteligente y rápido con bunny.net.

El Caos del Multi-CDN y la Dura Realidad de las Facturas

Para entender por qué hicieron el cambio, hay que ver cómo lucía antes su pipeline de imágenes.

Durante mucho tiempo, su stack de medios era un mosaico: diferentes CDNs manejando distintas partes de la plataforma, un servicio proxy para redimensionamiento dinámico, y assets crudos en almacenamiento cloud (AWS S3).

Cuando un usuario sube un JPEG de 10MB como portada de artículo, la app Rails no lo pre-procesa en docenas de dimensiones distintas. En su lugar, confían en transformación de imágenes en tiempo real. En teoría es ideal: el navegador solicita image.jpg?width=800, y un optimizador dinámico lo redimensiona, lo convierte a WebP o AVIF, y lo sirve.

En la práctica, la economía y mecánica de esta configuración a escala son brutales:

  • El impuesto del tráfico de scrapers: En la web abierta no solo sirves humanos. Lectores RSS, crawlers de búsqueda y scrapers de alta frecuencia te golpean constantemente. Una ola de scrapers agresivos solicitando variaciones no cacheadas forzaba al pipeline a re-procesar assets una y otra vez.
  • Tarifas de egress: Cada vez que el optimizador tenía que buscar una imagen cruda del almacenamiento cloud por un cache miss, pagaban tarifas elevadas.
  • Precios por transformación: Muchos CDNs de imágenes premium cobran “por cada mil imágenes procesadas”. Con millones de posts activos, esos costos se disparaban.
  • Fricción multi-CDN: Tener proveedores separados para cacheo HTML y entrega/optimización de imágenes creaba una sobrecarga operativa masiva.

“Nuestras facturas de medios se estaban inflando. Era increíblemente caro y pasábamos demasiado tiempo debuggeando por qué el pipeline no manejaba bien los picos de tráfico.”

Por qué Migraron a bunny.net

Ben, de DEV, había estado usando bunny.net por años en proyectos personales. Lo que realmente los convenció para Forem no fueron solo los ahorros en ancho de banda — aunque reducir las facturas a una fracción de lo que cobraban los CDNs empresariales fue una victoria masiva.

Fue cómo el ecosistema de productos manejaba sus puntos débiles específicos a través de la combinación de Bunny Optimizer y Edge Scripting.

1. Bunny Optimizer y Perma-Cache

Bunny Optimizer actúa como una API de transformación de imágenes totalmente gestionada. Lo conectas, agregas parámetros de URL simples (?width=600&height=300&crop=1:1), y el Optimizer maneja el redimensionamiento, recorte y compresión automática en tiempo real. Negocia formatos de nueva generación como WebP o AVIF automáticamente, reduciendo tamaños de archivo hasta en un 80% sin pérdida visible de calidad.

Pero la magia real está en Perma-Cache.

Normalmente, cuando un servidor edge del CDN desaloja una variante de imagen poco frecuente, la siguiente solicitud tiene que ir hasta el origen para re-procesarla, generando más tarifas de egress. Perma-Cache resuelve esto replicando permanentemente las variantes optimizadas en Bunny Storage.

Una vez que una imagen se procesa, se almacena en el edge para siempre. Nunca más tiene que tocar el origen en AWS.

2. Edge Scripting: Control Nativo con TypeScript

Mientras Bunny Optimizer daba el poder de redimensionar imágenes, necesitaban control granular sobre cómo servirlas. No querían contaminar sus vistas Rails con lógica compleja de construcción de URLs, y querían evitar que usuarios (o bots) descargaran imágenes crudas enormes.

Aquí entró Edge Scripting. Construido sobre Deno y V8, ejecuta JavaScript y TypeScript directamente en el edge, permitiendo escribir middleware liviano y type-safe que se ejecuta en milisegundos. Reemplazó por completo la necesidad de proxies de imagen personalizados o rutas complejas de Rails.

Bajo el Capó: El Servicio Images::Optimizer de Forem

En el código de Forem, el pipeline de imágenes siempre fue diseñado para ser conectable (“pluggable”). No querían hardcodear las vistas para usar los parámetros de un CDN específico.

Usan un patrón strategy simple. La clase Optimizer actúa como un router que mapea parámetros estandarizados (width, height, fit, gravity) al formato de URL específico del proveedor activo:

# app/services/images/optimizer.rb
module Images
  class Optimizer
    def self.call(url, options = {})
      case provider
      when :bunny
        BunnyProvider.call(url, options)
      when :cloudflare
        CloudflareProvider.call(url, options)
      when :fastly
        FastlyProvider.call(url, options)
      else
        url
      end
    end
  end
end

Cada proveedor implementa su propia estrategia de reescritura de URLs. Por ejemplo, el proveedor de bunny.net simplemente construye query strings estándar que Bunny Optimizer parsea.

Edge Scripting: Seguridad y Control sin Fricción

Un caso de uso real donde Edge Scripting brilló fue la prevención de hotlinking (robo de ancho de banda). Cuando detectan que un sitio externo está incrustando imágenes de DEV sin permiso, Edge Scripting reemplaza la imagen por un placeholder de marca, protegiendo el ancho de banda y asegurando que los recursos de la comunidad se usen apropiadamente.

Lo mejor es que esto pasa en el edge, sin que la aplicación Rails tenga que involucrarse. La capa de aplicación nunca tiene que pensar en lógica de fallback.

“Edge Scripting nos permite escribir políticas de seguridad y optimización que se ejecutan antes de que la solicitud toque nuestro origen.”

Mirando al Futuro: Video

Estabilizar el pipeline de imágenes fue solo la fase uno. El siguiente horizonte lógico es el video. La entrega de video es notoriamente compleja — requiere streaming con bitrate adaptativo (HLS/DASH), transcodificación multi-resolución, almacenamiento especializado y reproductores optimizados.

bunny.net es su primera opción para esto también, dado el éxito con su infraestructura de medios. Su enfoque de plataforma unificada se extiende directamente al streaming de video con productos que siguen la misma filosofía sensata y centrada en desarrolladores.

Reflexiones Finales

Como desarrolladores, a menudo nos enfocamos en optimizar consultas de base de datos, refactorizar código Ruby, o ajustar configuraciones de servidor. Pero a veces, las victorias más grandes están justo en tu pestaña de red.

“Las tarifas de egress y la entrega inflada de medios son un impuesto silencioso en las plataformas en crecimiento.”

Si estás ejecutando una plataforma con muchos medios o construyendo software comunitario open source como Forem, hazte un favor: mira tus facturas de CDN, revisa tu egress de almacenamiento cloud, y ve si puedes delegar parte de ese peso a una plataforma construida para crecer contigo. Tu presupuesto (y tus usuarios) te lo agradecerán.

¡Feliz código! ❤️