LibreDB Studio busca convertir su capa de proveedores en un SDK para terceros

LibreDB Studio, un IDE de bases de datos escrito en TypeScript que habla con varios motores SQL y NoSQL, tiene sobre la mesa una pregunta que su propio autor no ha resuelto: cómo abrir la capa de proveedores para que un tercero añada un motor sin tocar el núcleo. Hoy esa capa es deliberadamente estricta, y lo es a propósito: se diseñó para que sumar una base de datos fuera más seguro y obligara a modificar menos código central. El problema es que cada proveedor nuevo sigue entrando en el repositorio principal.

Un SDK estable y proveedores fuera del árbol

La idea que plantea es que LibreDB Studio exponga una API o SDK de proveedores estable. A partir de ahí, un desarrollador externo implementa el suyo por su cuenta, lo publica como paquete y el usuario lo instala o lo habilita sin esperar a una versión nueva del IDE. El núcleo del proyecto deja de tocarse cada vez que aparece un motor que soportar.

En el repositorio ya está documentado cómo se añade un proveedor hoy, y el autor explica en su blog cómo llegó a la arquitectura actual. Lo que no tiene cerrado es dónde poner la frontera. Se pregunta si el contrato del proveedor debe ser un paquete TypeScript versionado aparte, y si basta con npm más algún mecanismo de descubrimiento o hace falta un registro o marketplace propio.

Las dudas que no resuelve

Hay más preguntas abiertas, y ninguna es trivial. Cómo gestionar la compatibilidad entre proveedores y versiones de LibreDB Studio. Si los proveedores se cargan en tiempo de ejecución o se siguen empaquetando en el build; de momento tira por la carga dinámica. Y, sobre todo, qué hacer con el aislamiento y la seguridad de ejecutar código de terceros dentro de una aplicación web.

Aquí el autor reconoce que no lo tiene claro. Apunta que el producto es self-hosted y lo administra el propio equipo de sistemas de quien lo despliega, lo que rebaja parte del problema, pero no le sirve como respuesta. También pide referencias de proyectos que hayan resuelto esto bien.

El objetivo que se marca no es construir un sistema de plugins grande. Quiere la arquitectura más pequeña posible que le dé a un tercero un punto de extensión estable, y pide opinión a quien haya diseñado sistemas de extensiones en TypeScript o JavaScript y los haya puesto en producción.

De momento no hay release, ni fecha, ni diseño cerrado. Es una consulta abierta, y quien haya peleado con versionado de contratos, descubrimiento de paquetes y carga dinámica en un entorno web puede contestarla mejor que el propio mantenedor.