🧠 Conceptos Clave

Objetivo: Comprender por qué usamos Caddy en nuestro stack y cómo resuelve los desafíos de una arquitectura distribuida con múltiples aplicaciones.

🎯 El Problema Técnico

Arquitectura distribuida en desarrollo

En desarrollo necesitamos simular la misma arquitectura de producción que usa Reverse Proxy, pero con herramientas simples y configuración local.

Producción (Reverse Proxy):

HAProxy Rules → Tenant ASP.NET
              → Landings
              → Pasarela de Pagos

Desarrollo (Caddy):

Caddy Handlers → localhost:80 (Tenant local)
               → localhost:5250 (Landings local)
               → pagos.XXXXX.com (Servicio remoto)

Desafíos técnicos específicos

1. Routing por path:

/ofertas/* → Aplicación de landings
/payment/* → Pasarela de pagos
/* → Aplicacion principal (fallback)

2. Transformación de URLs:

Input:  /ofertas/decameron
Output: /render/decameron (a servicio de landings)

3. Headers específicos:

Host: Preservar dominio original
x-origin-site: Identificar tenant/sitio
HTTP_X_FRONTEND_HTTPS: Indicar protocolo HTTPS

¿Por qué Caddy para desarrollo?

Vs configurar cada servicio manualmente:

❌ Configurar CORS en 5+ aplicaciones
❌ Generar certificados SSL para cada puerto
❌ Recordar qué puerto corre cada servicio
❌ URLs localhost:PORT diferentes para cada dev

Con Caddy:

✅ Una configuración centralizada
✅ HTTPS automático para todos los servicios
✅ URLs consistentes entre todos los devs
✅ Simula exactamente el comportamiento de producción

🛡️ Decisiones de Seguridad y Performance

¿Por qué `auto_https disable_redirects`?

{
    auto_https disable_redirects
}

El problema sin esta configuración:

IIS corre en puerto 80 (HTTP) por defecto en desarrollo
Caddy quiere manejar puerto 80 para redirects HTTP → HTTPS
Conflicto: Ambos intentan usar puerto 80
Error: bind: address already in use

La solución:

disable_redirects permite que IIS mantenga puerto 80
Caddy solo maneja HTTPS (puerto 443)
Desarrolladores acceden directamente via HTTPS
Resultado: Coexistencia pacífica

Headers específicos explicados

reverse_proxy localhost:5000 {
    header_up Host {host}                    # Preserva dominio original
    header_up x-origin-site mi-motor.local  # Identifica origen para el backend
    header_up HTTP_X_FRONTEND_HTTPS on      # Indica que viene de HTTPS
}

¿Por qué cada header?

Host {host}: El backend ASP.NET necesita saber el dominio real para generar URLs correctas
x-origin-site: Configuración multisitio - el backend decide qué configuración usar
HTTP_X_FRONTEND_HTTPS on: Compatibility con aplicaciones que verifican HTTPS

CORS en desarrollo

(cors) {
    header {
        Access-Control-Allow-Origin "{header.origin}"
        Access-Control-Allow-Credentials "true"
        Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE"
    }
}

Permisivo en desarrollo, estricto en producción:

Desarrollo: Permite cualquier origen para testing
Producción: Solo dominios específicos autorizados

🎯 Beneficios vs Complejidad

✅ Beneficios de nuestra arquitectura

Para desarrollo:

Simula HAProxy localmente: Mismo routing logic, herramientas simples
Mix flexible: Algunos servicios locales, otros remotos según lo que desarrolles
Setup una vez: Configuración reutilizable entre developers
Debug distribuido: Logs centralizados de todo el routing

Para arquitectura:

Separación de responsabilidades: Cada aplicación hace una cosa bien
Especialización técnica: Landings en tech A, pagos en tech B, etc.
Deployment independiente: Deploy sin afectar otras aplicaciones
Resilencia: Falla de una aplicación no tumba el sistema completo

¿Vale la pena? SÍ - Setup inicial más complejo, pero desarrollo mucho más realista y menos debugging de integración.

⚠️ Complejidades que manejamos

Red y routing:

Configuración inicial más compleja que monolito
Debug distribuido requiere entender flujo completo
DNS local requiere configuración en cada máquina

Desarrollo:

Developers necesitan entender arquitectura distribuida
Setup inicial más largo que npm start
Algunos bugs solo aparecen en integración completa

🔄 Próximos Pasos

Ahora que entiendes la arquitectura y el “por qué”:

🔧 Configuraciones: Profundiza en handlers, snippets y configuraciones avanzadas
🚨 Troubleshooting: Soluciones a problemas comunes