The Daily Newsstand · Free, Always
Sunday, September 13, 2026

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

Translate

Я работал над архитектурой 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-приложений в продакшене.

View the original on Хабр

KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.