ResultSink. La persistencia y protección de store mode las define el host/sink; el Worker independiente gestiona cifrado, almacenamiento y HMAC.
Código fuente disponible
Fetcher está disponible como código fuente bajo la Elastic License 2.0. El código fuente completo vive en GitHub, y cada archivo fuente del Engine lleva un encabezado
SPDX-License-Identifier: Elastic-2.0. Fetcher y Midaz son los dos productos de Lerian.
Dos formas de ejecutarlo
La dualidad de abajo es la forma del producto. Elige la fila que corresponde a tu problema.
El Engine es un módulo Go separado del módulo de los servicios (
github.com/LerianStudio/fetcher/v2). Actualmente declara cero dependencias de terceros. CI aplica el límite de dependencias rechazando grafos que no sean de stdlib o del módulo local, no comprobando sintácticamente un bloque require. Tu aplicación anfitriona provee las partes que el Engine necesita a través de interfaces pequeñas, llamadas puertos.
El Manager y el Worker usan ese mismo Engine para la extracción genérica. El Worker conserva una ruta de compatibilidad separada para la extracción plugin_crm de MongoDB.
El Engine incluye un arnés en memoria (
pkg/engine/memory) que cubre los puertos de almacenamiento: el registro de conectores, el connection store, la caché de esquemas, el result sink y el execution store. Puedes correr una extracción real sin MongoDB, sin RabbitMQ y sin almacenamiento de objetos. El arnés no cubre la protección de credenciales: la persistencia cifrada viene desactivada por defecto y activarla exige que tu aplicación anfitriona provea un CredentialProtector. Consulta Primeros pasos.Lo que te da Fetcher
- Gestión de conexiones. Guarda, valida y prueba conexiones a bases de datos. Fetcher cifra cada contraseña con AES-256-GCM antes de escribir el registro.
- Descubrimiento de esquema. Fetcher detecta tablas, columnas y tipos de datos en los cinco tipos de base de datos, con una caché y una lectura siempre fresca.
- Extracción de datos. Una sola interfaz de consulta con proyección de campos, diez operadores de filtro y peticiones multi-tabla, multi-esquema y multi-datasource.
- Orquestación de jobs. Procesamiento asíncrono con una ventana de duplicados de 5 minutos, seguimiento de estado y eventos
job.completedyjob.failed.
Datasources
Fetcher acepta cinco tipos de datasource. Envía el identificador en mayúsculas en la API: la validación de la solicitud compara exactamente esos cinco valores, y
postgresql se rechaza con 400. Los datasources internos que declara el operador (DATASOURCE_{NAME}_TYPE) y el filtro de consulta type del listado de conexiones sí aceptan cualquier capitalización.
Seguro por construcción
- Alcance de tenant. Cada operación del Engine lleva un ID de tenant, y ese ID es el único límite de aislamiento. Un ID de tenant mal formado falla antes de que Fetcher toque cualquier recurso.
- Errores redactados. Fetcher descarta el error crudo del driver en su frontera, así que un DSN, una credencial o un detalle interno del driver no llegan a quien llama.
- Extracción que falla rápido. El primer paso que falla detiene la ejecución. Fetcher nunca devuelve un resultado parcial.
- Límites predeterminados. Los valores predeterminados son 10 datasources, 20 tablas por datasource, 50 campos por tabla, 4 workers concurrentes por datasource, 5 minutos y 256 MiB. El host configura el techo; una solicitud solo puede reducirlo.
- Validación de host. En modo multi-tenant, Fetcher rechaza un host provisto por el tenant que resuelve a una dirección privada, de loopback o de metadatos de nube.
Próximos pasos
Casos de uso
Problemas concretos que Fetcher resuelve, y qué cambia cuando lo adoptas.
Primeros pasos
Dos caminos hacia una primera extracción: sin infraestructura, o con el stack completo de Docker.
Conceptos centrales
Conexiones, descubrimiento de esquema, jobs de extracción, filtros y resultados.
Seguridad
Clave maestra, claves derivadas, firma de mensajes y validación de host.

