DEV Community

Cover image for Designing a plugin architecture for third-party database providers in a TypeScript application
Cevheri
Cevheri

Posted on

Designing a plugin architecture for third-party database providers in a TypeScript application

#architecture #backend #database #typescript

I've been working on the architecture of LibreDB Studio, a TypeScript-based database IDE that supports multiple SQL/NoSQL databases

While working on the provider layer, I ended up designing a fairly strict provider architecture to make adding new databases safer and reduce the amount of core code that needs to change

I wrote about the architecture here: https://libredb.org/blog/building-universal-database-provider-typescript/

The current process for adding a provider is documented here: https://github.com/libredb/libredb-studio/blob/main/docs/ADDING_A_PROVIDER.md

The Architecture is working reasonably well, but it raised a bigger question for me

Currently, adding a new provider still means adding it to the main Libredb-Studio codebase. I'd like to eventually move toward something more like a plugin ecosystem:

  • libredb studio provides a stable provider SDK/API.
  • A third-party developer can implement a new database provider independently.
  • The provider can be published as a package/library.
  • Users can install or enable that provider without waiting for a new Libredb Studio release.
  • The core application doesn't need to be modified every time a new database is supported.

Conceptually, something like:

libredb-studio

|

+-- Provider SDK / API

|

+-- PostgreSQL provider

+-- MySQL provider

+-- MongoDB provider

+-- Third-party provider

+-- ...
Enter fullscreen mode Exit fullscreen mode

I'm considering different approaches for the distribution/discovery side as well: npm packages, a provider registry/marketplace, or some combination of these.

but I'm not sure where the right boundary is.

for example:

  • Should the provider contract be a completely separate, versioned TypeScript SDK package?
  • Is npm + a manifest/discovery mechanism enough, or does a dedicated registry/marketplace make more sense?
  • How would you handle provider/API compatibility across LibreDB Studio releases?
  • Should providers be dynamically loaded at runtime, or should they still be bundled/installed at build time?(for now: dynamic load)
  • Since this is a web application, how would you approach the security/isolation implications of loading third-party provider code?
  • Are there established architectures/projects that handle this problem particularly well?(I am not sure: selfhosted and system admin managed this OK, but I am confused, security/comfortable ...)

The goal isn't necessarily to build a huge plugin system. I'd prefer the smallest architecture that gives third-party developers a stable extension point.

I'd especially appreciate opinions from people who have designed plugin/extension systems for TypeScript/JavaScript applications in production.

What would you consider the "right" architecture for this?

Top comments (0)