Проектирование архитектуры плагинов для сторонних провайдеров баз данных в TypeScript-приложении


Я работал над архитектурой LibreDB Studio — IDE для баз данных на TypeScript, которая поддерживает несколько SQL/NoSQL баз данных.
Работая над слоем провайдеров, я пришёл к довольно строгой архитектуре провайдеров, чтобы сделать добавление новых баз данных безопаснее и сократить объём основного кода, который нужно менять.
Я написал об этой архитектуре здесь:
https://libredb.org/blog/building-universal-database-provider-typescript/
Текущий процесс добавления провайдера задокументирован здесь:
https://github.com/libredb/libredb-studio/blob/main/docs/ADDING_A_PROVIDER.md
Архитектура работает достаточно хорошо, но у меня возник более широкий вопрос.
Сейчас добавление нового провайдера по-прежнему означает добавление его в основную кодовую базу Libredb-Studio. В конечном итоге я хотел бы перейти к чему-то более похожему на экосистему плагинов:
libredb studio предоставляет стабильный SDK/API провайдера.
Сторонний разработчик может независимо реализовать новый провайдер базы данных.
Провайдер можно опубликовать как пакет/библиотеку.
Пользователи могут установить или включить этого провайдера, не дожидаясь нового релиза Libredb Studio.
Основное приложение не нужно модифицировать каждый раз, когда добавляется поддержка новой базы данных.
Концептуально это выглядит примерно так:
text
libredb-studio
|
+-- Provider SDK / API
|
+-- PostgreSQL provider
+-- MySQL provider
+-- MongoDB provider
+-- Third-party provider
+-- ...Я также рассматриваю разные подходы к распространению/обнаружению: npm-пакеты, реестр/маркетплейс провайдеров или некоторая комбинация.
Но я не уверен, где находится правильная граница.
Например:
Должен ли контракт провайдера быть полностью отдельным, версионируемым пакетом TypeScript SDK?
Достаточно ли npm + механизма манифестов/обнаружения, или больше смысла имеет выделенный реестр/маркетплейс?
Как обрабатывать совместимость провайдеров/API между релизами LibreDB Studio?
Должны ли провайдеры загружаться динамически во время выполнения или всё ещё должны включаться в сборку/устанавливаться на этапе сборки? (пока: динамическая загрузка)
Поскольку это веб-приложение, как подходить к вопросам безопасности/изоляции при загрузке кода сторонних провайдеров?
Есть ли устоявшиеся архитектуры/проекты, которые особенно хорошо решают эту проблему? (Я не уверен: при self-hosted и управлении системным администратором это нормально, но я запутался в безопасности/комфорте...)
Цель не обязательно в создании огромной плагинной системы. Я предпочёл бы минимальную архитектуру, которая даёт сторонним разработчикам стабильную точку расширения.
Особенно буду признателен за мнения тех, кто проектировал плагинные/расширяемые системы для TypeScript/JavaScript-приложений в продакшене.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.