Saltar al contenido principal
El modelo de Fetcher es pequeño: registras conexiones a bases de datos externas, Fetcher descubre sus esquemas, y envías jobs de extracción que producen resultados firmados y cifrados. Esta página recorre cada pieza.

​
Conexiones

Una conexión es una referencia nombrada y almacenada a una base de datos externa — su tipo, host, puerto, nombre de la base y credenciales. Fetcher soporta cinco tipos de conexión: POSTGRESQL, MYSQL, ORACLE, SQL_SERVER y MONGODB.
  • Las credenciales se cifran en reposo con AES-256-GCM antes de llegar al almacenamiento; las contraseñas en texto claro nunca persisten.
  • Las conexiones se pueden probar: un endpoint dedicado abre una conexión real y reporta la latencia, para que valides una conexión antes de que cualquier job dependa de ella.
  • Las conexiones en uso están protegidas: actualizar o eliminar una conexión con jobs activos se rechaza.
Además de las conexiones registradas por la API, los operadores pueden definir datasources internos directamente por variables de entorno (DATASOURCE_{NAME}_*) — útil para bases fijas, propiedad de la plataforma. Consulta Configuración.

​
Descubrimiento de esquemas

Fetcher detecta automáticamente tablas, columnas y tipos de datos en las bases a las que se conecta — el mismo descubrimiento funciona en los cinco tipos de base de datos. Para bases relacionales lee el catálogo, incluyendo namespaces multi-schema (schemas de PostgreSQL, owners de Oracle, schemas de SQL Server). Para MongoDB, donde las colecciones no tienen esquema declarado, Fetcher infiere uno mediante muestreo estadístico de documentos. Dos cosas se apoyan en el descubrimiento:
  • Validación de esquema: antes de ejecutar un job, puedes validar que las tablas y campos que planeas extraer realmente existen en los datasources.
  • Caché de esquemas: los esquemas descubiertos se guardan en caché (con TTL configurable), para no reintrospectar la base en cada job repetido.

​
Jobs de extracción

Un job es una solicitud asíncrona de extracción de datos. Su corazón es el mapa mappedFields — qué campos, de qué tablas, de qué datasources: 
{
  "dataRequest": {
    "mappedFields": {
      "mi_postgres": {
        "accounts": ["id", "email", "created_at"]
      },
      "mi_mongo": {
        "transactions": ["*"]
      }
    }
  }
}
  • Proyección de campos: nombra los campos que quieres, o usa ["*"] para todos los campos.
  • Multi-todo: un solo job puede abarcar múltiples datasources, múltiples tablas por datasource y múltiples schemas.
  • Manejo de JSON: los campos JSON/JSONB en bases relacionales se interpretan automáticamente.

​
Filtros

Los jobs pueden filtrar filas por tabla con un conjunto de 10 operadores: eq, ne, gt, gte, lt, lte, between, in, nin y like. 
{
  "dataRequest": {
    "filters": {
      "mi_postgres": {
        "transactions": {
          "status": { "in": ["completed", "pending"] }
        }
      }
    }
  }
}

​
Ciclo de vida del job

EstadoSignificado
pendingAceptado y encolado; aún no tomado por un Worker
processingUn Worker está extrayendo los datos
completedResultados almacenados y evento de finalización publicado
failedLa extracción falló; el evento de fallo fue publicado
Los jobs se deduplican: una solicitud idéntica dentro de una ventana de 5 minutos devuelve el job existente en lugar de crear uno nuevo. En estados terminales, el Worker publica eventos de notificación job.completed / job.failed, para que los consumidores reaccionen sin hacer polling.

​
Resultados

El Worker escribe los resultados de la extracción en object storage — SeaweedFS por defecto, o cualquier servicio compatible con S3:
  • Cifrados en reposo, con TTL de retención configurable.
  • Firmados: cada documento extraído lleva una firma HMAC-SHA256. Los consumidores pueden derivar la clave de verificación a partir de la clave maestra y comprobar la autenticidad de lo que leen — los datos provienen comprobadamente de Fetcher y no fueron alterados.

​
Servicios y el Engine

Dos formas de despliegue comparten un único núcleo:
  • Servicios standalone — el Manager (API HTTP, metadatos en MongoDB, despacho de jobs vía RabbitMQ) y el Worker (consumidor de cola, extracción, almacenamiento de resultados). Es la forma que ejecuta la guía de primeros pasos.
  • Engine embebido — el núcleo de extracción (pkg/engine) como un módulo Go importable, con cero dependencias de terceros. Las aplicaciones anfitrionas conectan su propia infraestructura a las interfaces del Engine y ejecutan extracciones en su propio proceso. Sin un almacén de resultados, el Engine corre en modo Direct: los resultados vuelven inline con un digest de integridad SHA-256.
La regla práctica: el Engine es dueño de qué significa la extracción — planificación, validación, límites, aislamiento de tenant; el host (Manager/Worker, o tu aplicación) es dueño de cómo se ejecuta — colas, almacenamiento, autenticación, ciclo de vida.

​
Tenancy

Fetcher corre single-tenant por defecto. En modo multi-tenant, toda operación se limita a un tenant resuelto a partir del contexto de tenant basado en JWT, y cada tenant recibe bases de metadatos, namespaces de caché y rutas de object storage aisladas. Los caminos de código multi-tenant tienen costo cero cuando el modo está deshabilitado. Consulta Multi-tenancy para el modelo de la plataforma.

​
Próximos pasos

Primeros pasos

Ejecuta Fetcher localmente y corre tu primer job de extracción.

Configuración

Las variables de entorno que dan forma a un despliegue de Fetcher.