Skip to main content
Fetcher lee datos de bases de datos que tu aplicación no controla. Se conecta a PostgreSQL, MySQL, Oracle, SQL Server y MongoDB, descubre tablas y campos, y extrae las filas que pides. Fetcher independiente suministra la API HTTP y el almacenamiento de conexiones. El Engine embebido es una API de Go cuyo host suministra el registro de conectores y los puertos de conexión o credenciales que necesite. Para la extracción genérica, Fetcher valida la selección contra un snapshot de esquema con caché primero y descubre en vivo si falta en caché. El modo directo embebido devuelve JSON en texto plano con integridad SHA-256 cuando no hay 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


  1. 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.
  2. 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.
  3. 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.
  4. Orquestación de jobs. Procesamiento asíncrono con una ventana de duplicados de 5 minutos, seguimiento de estado y eventos job.completed y job.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.