Deja de reconstruir el acceso a datos en cada servicio
El problema. Lerian pasó por esto internamente. Cada equipo de producto construyó su propia lógica de acceso a datos contra las mismas bases de datos externas, y cada copia envejeció por separado. Fetcher existe para centralizar ese trabajo. El mismo patrón aparece en cualquier empresa que corre varios sistemas internos contra las mismas bases de datos operativas. Cada equipo escribe su propio pool de conexiones, su propio manejo de secretos y su propio constructor de consultas. Es el mismo trabajo, hecho cinco veces. Qué cambia. Una conexión externa pertenece a un producto. Los consumidores de ese producto pueden reutilizarla; el
metadata.source de un job debe coincidir con el producto de la conexión. Fetcher cifra la contraseña una vez, prueba la conexión cuando lo pides y aplica los mismos diez operadores de filtro a los cinco tipos de base de datos. Un consumidor nuevo no registra drivers ni guarda credenciales. Llama a una API.
Agregar un tipo de datasource pasa a ser trabajo de un equipo en lugar de trabajo de cinco.
Alimenta conciliación y reportes desde bases de datos operativas
El problema. La conciliación y la generación de reportes necesitan filas que viven fuera de la plataforma. Esas filas están en el PostgreSQL operativo de un banco, en el MySQL de un socio o en un almacén de clientes en MongoDB. El producto consumidor tiene que alcanzarlas sin volverse él mismo un cliente de base de datos. Qué cambia. Para datasources genéricos, el Worker valida las tablas y los campos seleccionados durante la planificación antes de consultar datos. Esa validación usa un snapshot de esquema con caché primero, por lo que un acierto de caché no es una comprobación contra el esquema vivo. La ruta de compatibilidad
plugin_crm es separada. El Worker escribe los resultados del servicio independiente en almacenamiento de objetos y publica job.completed o job.failed; el consumidor reacciona al evento.
En modo single-tenant, Fetcher carga datasources internos fijos desde variables de entorno DATASOURCE_{NAME}_*. En modo multi-tenant, los resuelve por tenant mediante Tenant Manager. En ambos modos son conexiones internas en memoria y no necesitan un registro de conexión en MongoDB.
Publica un extracto que un tercero puede verificar
El problema. Envías un extracto de datos a un auditor, a un regulador o a un socio. Necesitan pruebas de que el archivo salió de tus sistemas y de que nadie lo editó en tránsito. Qué cambia. El Worker firma el JSON en texto plano con HMAC-SHA256 antes de cifrar el payload, y después guarda el resultado con cifrado AES-GCM en reposo. Quien lo recibe deriva la clave externa de verificación desde tu clave maestra con el comando
make derive-key, y comprueba la firma de forma independiente.
Esa clave derivada solo verifica firmas. No puede descifrar credenciales almacenadas, y no puede falsificar mensajes internos entre el Manager y el Worker.
Agrega extracción a un servicio que ya operas
El problema. Necesitas extracción dentro de un solo servicio Go. Levantar un Manager, un Worker, MongoDB, RabbitMQ y almacenamiento de objetos cuesta más que la funcionalidad. Qué cambia. Tu servicio importa el módulo del Engine y lo llama en proceso. El Engine no tiene dependencias de terceros, así que la importación no agrega superficie operativa. Sin ningún sink de resultados conectado, el Engine corre en modo directo y devuelve las filas en línea como JSON indentado, con un digest SHA-256 sobre los bytes exactos. Esa salida es determinista. La misma entrada produce un JSON idéntico byte a byte y el mismo digest, sin importar en qué orden terminaron los pasos paralelos por datasource. Puedes persistir esos bytes y firmarlos tú mismo.
Sirve a muchos tenants desde un solo despliegue
El problema. Corres un solo Fetcher para muchos clientes. Cada cliente registra sus propios hosts de base de datos. Un cliente nunca debe leer las filas de otro, y ningún cliente puede apuntar una conexión a tu red interna. Qué cambia. El modo multi-tenant resuelve recursos de metadatos desde el contexto de tenant que suministra el middleware de tenant. El acceso falla cerrado: una solicitud sin base de datos de tenant resuelta devuelve un error en lugar de leer una base de datos compartida. El mismo interruptor activa la validación de host. Fetcher rechaza un host provisto por el tenant que resuelve a una dirección privada, de loopback o de metadatos de nube. Revisa una dirección IP literal al parsear la petición, y de nuevo el nombre de host en la fábrica de datasources. Los datasources internos configurados por el operador quedan exentos.
Próximos pasos
Primeros pasos
Corre 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.