|
| 1 | +--- |
| 2 | +title: Plugin Architecture |
| 3 | +description: The Extension Model and Microkernel Philosophy of ObjectStack. |
| 4 | +--- |
| 5 | + |
| 6 | +# Plugin Architecture |
| 7 | + |
| 8 | +ObjectStack follows a strict **Microkernel Architecture**. The core platform provides only the minimal runtime environment (Kernel), while all business capabilities, including standard ones like CRM or Project Management, are delivered as **Packages** (Apps or Plugins). |
| 9 | + |
| 10 | +## 1. Philosophy: "Kernel + Plugins" |
| 11 | + |
| 12 | +* **The Kernel**: Responsible for booting, identity, permission enforcement, and loading the manifest. It knows *nothing* about "Leads", "Tasks", or even "Kanban Boards" initially. |
| 13 | +* **The Plugins**: Teach the Kernel new tricks. |
| 14 | + * **Apps**: Combinations of data and UI for end-users (e.g., "Sales App"). |
| 15 | + * **Plugins**: Extensions to the system capabilities (e.g., "BI Engine", "SAML Auth", "Stripe Payment"). |
| 16 | + |
| 17 | +This separation ensures the platform remains lightweight and un-opinionated, allowing it to evolve indefinitely. |
| 18 | + |
| 19 | +## 2. Anatomy of a Plugin |
| 20 | + |
| 21 | +A plugin is defined by its `Manifest` (objectstack.config.ts). The most critical part of a modern ObjectStack plugin is the `contributes` section. |
| 22 | + |
| 23 | +### The `contributes` Protocol |
| 24 | + |
| 25 | +Inspired by VS Code, we use a declarative approach to register capabilities. |
| 26 | + |
| 27 | +```typescript |
| 28 | +// objectstack.config.ts |
| 29 | +export default { |
| 30 | + id: 'com.vendor.bi', |
| 31 | + type: 'plugin', |
| 32 | + |
| 33 | + // DECLARATIVE: "I bring these new capabilities" |
| 34 | + contributes: { |
| 35 | + // 1. Define new Metadata Kinds (File Types) |
| 36 | + kinds: [ |
| 37 | + { |
| 38 | + id: 'bi.dataset', |
| 39 | + globs: ['**/*.dataset.json'], |
| 40 | + description: 'BI Dataset Definition' |
| 41 | + } |
| 42 | + ], |
| 43 | + // 2. Define new UI Locations |
| 44 | + views: [ |
| 45 | + { |
| 46 | + id: 'bi.chart_renderer', |
| 47 | + location: 'dashboard.widget' |
| 48 | + } |
| 49 | + ] |
| 50 | + }, |
| 51 | + |
| 52 | + // IMPERATIVE: "Here is the code to handle them" |
| 53 | + lifecycle: './src/index.ts' |
| 54 | +} |
| 55 | +``` |
| 56 | + |
| 57 | +## 3. Extension Capabilities |
| 58 | + |
| 59 | +### A. New Metadata Kinds (CRDs) |
| 60 | + |
| 61 | +This is the most powerful feature. A plugin can introduce entirely new concepts to the platform. |
| 62 | + |
| 63 | +* **Example**: A "BI Plugin" introduces `*.dataset.json` and `*.report.json`. |
| 64 | +* **Mechanism**: The Kernel uses the `contributes.kinds` registry to map file extensions to the plugin's parser. |
| 65 | +* **Result**: The IDE (cursor/vscode) and Runtime automatically recognize these files. |
| 66 | + |
| 67 | +### B. Service Providers |
| 68 | + |
| 69 | +Plugins can implement standard interfaces defined by the system. |
| 70 | + |
| 71 | +* **Auth Providers**: `plugin extends AuthProvider` (SAML, OAuth). |
| 72 | +* **Storage Drivers**: `plugin extends StorageDriver` (S3, MinIO). |
| 73 | +* **Notification Channels**: `plugin extends NotificationChannel` (Slack, SMS). |
| 74 | + |
| 75 | +## 4. Plugin Lifecycle |
| 76 | + |
| 77 | +The runtime manages the plugin states: |
| 78 | + |
| 79 | +1. **Resolve**: Read Manifest, validate dependencies. |
| 80 | +2. **Install (`onInstall`)**: Run migration scripts, setup initial data. |
| 81 | +3. **Boot (`onBoot`)**: Register generic services (before App load). |
| 82 | +4. **Enable (`onEnable`)**: Active and serving traffic. |
| 83 | + |
| 84 | +```typescript |
| 85 | +export class BiPlugin implements PluginLifecycle { |
| 86 | + async onEnable(context: PluginContext) { |
| 87 | + // Register the heavy engine only when enabled |
| 88 | + context.services.register('bi.engine', new BiAnalysisEngine()); |
| 89 | + } |
| 90 | +} |
| 91 | +``` |
0 commit comments