Проектирование архитектуры плагинов для сторонних провайдеров баз данных в 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-приложений в продакшене.

Какую архитектуру вы считаете «правильной» для этого?

#sql #nosql #database #typescript #javascript