GM
ES/EN
Volver a proyectos

Herramientas de desarrollo / Windows

DevProxy Studio

Proxy reverso modular que expone aplicaciones locales a la red y captura, persiste e inspecciona todo el tráfico HTTP que las atraviesa.

Rol: Arquitectura, backend y experiencia de escritorio Duración: Proyecto propio, cuatro fases entregadas 2026

El problema

Probar una aplicación local desde un dispositivo real —un teléfono, una tableta industrial— exige exponerla a la red, y entender qué está fallando exige ver el tráfico. Las herramientas existentes resuelven una cosa o la otra: descubrir qué está escuchando, exponerlo y luego inspeccionar la conversación implica encadenar tres utilidades distintas.

Camino de captura — el disco nunca toca el camino caliente La petición atraviesa el proxy y se encola; un trabajador aparte persiste en lotes. Petición CLIENTE Proxy KESTREL · YARP Cola CANAL ACOTADO Trabajador SEGUNDO PLANO SQLite ESCRITURA EN LOTES El canal está acotado: bajo presión sostenida descarta registros en lugar de crecer sin techo.
Camino de captura — el disco nunca toca el camino caliente

Restricciones

  • La captura no puede penalizar la latencia del tráfico que atraviesa el proxy
  • Cada proxy debe arrancar, detenerse y reiniciarse sin afectar a los demás
  • La interfaz debe seguir respondiendo mientras se escriben miles de registros

Decisiones

Decidí Encolar cada intercambio en un canal acotado y persistirlo en lotes desde un trabajador en segundo plano
En lugar de Escribir a la base de datos en el mismo camino que atiende la petición
Porque El camino caliente del proxy no debe esperar por el disco. El canal acotado además fija un techo de memoria — bajo presión se descarta, en lugar de crecer sin límite.
Decidí Un host propio por cada proxy, con ciclo de vida independiente
En lugar de Un host compartido con enrutamiento por reglas
Porque Reiniciar la configuración de un proxy no debería interrumpir los demás. El aislamiento cuesta memoria y ahorra incidentes.
Decidí Separar el dominio de la interfaz, la persistencia y la librería de proxy
En lugar de Construir sobre la aplicación de escritorio directamente
Porque Las tres dependencias externas son sustituibles; las reglas del producto no. La dirección de las dependencias lo refleja.

Resultado

  • Ciclos de vida de proxy independientes — arranque, parada y reinicio por instancia
  • Captura sin bloqueo con persistencia en lotes
  • Inspector de petición y respuesta con formateo, descompresión y diagnóstico de errores del destino
  • Descubrimiento de puertos en escucha y del proceso que los ocupa, con exposición a la red en un clic

El camino caliente y el camino frío

La decisión que define el proyecto es dónde ocurre la escritura. Un proxy que persiste cada intercambio dentro del camino de la petición añade la latencia del disco a cada llamada que pasa por él, lo que arruina la herramienta justo cuando más se necesita: bajo carga.

La captura encola en un canal acotado y un trabajador en segundo plano escribe en lotes. El canal está acotado a propósito: bajo presión sostenida se descartan registros en lugar de consumir memoria sin techo. Un diagnóstico incompleto es recuperable; un proceso que agota la memoria de la máquina no lo es.

Por qué las capas

El dominio no conoce la interfaz, ni la base de datos, ni la librería de proxy. Las tres son sustituibles y las reglas del producto no. La consecuencia práctica se vio al añadir el descubrimiento de puertos: entró como un adaptador nuevo, sin tocar el núcleo.

Por qué está aquí

Porque es un caso donde la arquitectura se justifica con una razón concreta —proteger la latencia y la memoria— y no con la costumbre de dividir en capas.