[Design Discussion] Compile time / Runtime Plugin Architecture for Thunder Frontends

[brionmario]

Related Feature Issue

• Compile time / Runtime Plugin Architecture for Thunder Frontends #1236

Problem Summary

Thunder frontends (apps and tooling) currently lack a flexible plugin system. Teams cannot easily add new functionality dynamically, which slows down experimentation, increases duplication of effort, and limits the platform’s extensibility.

The goal is to allow developers to extend apps or tooling either at compile time or runtime without needing to modify core codebases.

High-Level Approach

• Introduce a plugin system with two modes:
  1. Compile-time plugins: Bundled with the app at build time, used for core or critical extensions.
  2. Runtime plugins: Dynamically loaded during app execution, supporting third-party modules or feature experiments.
• Define a plugin API and manifest format for consistent registration of components, routes, or services.
• Provide tooling for building, testing, and deploying plugins.

Architecture Overview

• Plugin Registry: Centralized mechanism to register and resolve plugins.
• Core App: Loads compile-time plugins during the build process.
• Runtime Loader: Fetches and integrates runtime plugins dynamically.
• Plugin Sandbox: Ensures isolation of runtime plugins to prevent conflicts.
• Manifest/Metadata: Defines plugin dependencies, entry points, and exposed capabilities.
• Communication Layer: Event bus or API contracts for plugin-core interaction.

Diagram (conceptual):

[Core App] --loads--> [Compile-time Plugins]
          \
           --runtime loader--> [Runtime Plugins]
[Plugin Registry] <--> [Event Bus / API]

Security Considerations

• Ensure runtime plugins are sandboxed to prevent malicious code execution.
• Validate plugin manifests to avoid unauthorized access to core app APIs.
• Consider code signing or trusted sources for third-party plugins.
• Define strict boundaries for plugin interaction with the core application.

Impacted Areas

• All Thunder frontends (apps & tooling) adopting the plugin architecture.
• CI/CD pipelines for building apps with compile-time plugins.
• Documentation and developer guides for plugin creation and deployment.
• Testing infrastructure to include plugin integration tests.

Alternatives Considered

1. Monolithic architecture: Continue current approach, limited extensibility, higher maintenance overhead.
2. Micro frontends for all extensions: Provides modularity but increases complexity and runtime overhead.
3. Feature flags for dynamic behavior: Limited flexibility compared to a full plugin system.
4. Hybrid approach with only runtime plugins: Simplifies build but reduces compile-time guarantees and performance optimizations.

Questions for Community Input

1. Plugin Scope & Use Cases

   • What types of extensions do you expect to build as plugins (UI components, routes, services, utilities)?
   • Are there specific workflows or apps that would benefit most from runtime vs compile-time plugins?

2. Plugin API & Manifest Design

   • What fields or metadata should a plugin manifest include?
   • How should plugins declare dependencies on other plugins or core services?

3. Runtime Loading & Sandboxing

   • What level of isolation should runtime plugins have from the core app?
   • Should we allow plugins to communicate via a shared event bus, or strictly through defined APIs?

4. Security & Trust

   • What mechanisms should we adopt to ensure runtime plugins are safe to load (code signing, trusted sources, manifest validation)?
   • Are there potential attack vectors we might have missed?

5. Development & Tooling Experience

   • What tooling would make plugin development and testing easier (CLI scaffolds, hot reload, integrated dev server)?
   • How should we structure compile-time vs runtime plugin builds in CI/CD pipelines?

6. Compatibility & Versioning

   • How should we handle version mismatches between plugins and core apps?
   • Should we allow multiple versions of a plugin to coexist?

7. Community Adoption & Contribution

   • How can we make the plugin system approachable for internal teams vs third-party contributors?
   • Are there any existing examples or inspiration from other ecosystems (e.g., VS Code, Figma, Webpack plugins) we should consider?

8. Alternatives & Trade-offs

   • Are there other architectural approaches that could achieve similar flexibility without a full plugin system?
   • What trade-offs should we prioritize (performance, flexibility, simplicity, security)?