|
| 1 | +--- |
| 2 | +title: Extension Architecture |
| 3 | +sidebar_position: 1 |
| 4 | +--- |
| 5 | + |
| 6 | +<!-- |
| 7 | +Licensed to the Apache Software Foundation (ASF) under one |
| 8 | +or more contributor license agreements. See the NOTICE file |
| 9 | +distributed with this work for additional information |
| 10 | +regarding copyright ownership. The ASF licenses this file |
| 11 | +to you under the Apache License, Version 2.0 (the |
| 12 | +"License"); you may not use this file except in compliance |
| 13 | +with the License. You may obtain a copy of the License at |
| 14 | +
|
| 15 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 16 | +
|
| 17 | +Unless required by applicable law or agreed to in writing, |
| 18 | +software distributed under the License is distributed on an |
| 19 | +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| 20 | +KIND, either express or implied. See the License for the |
| 21 | +specific language governing permissions and limitations |
| 22 | +under the License. |
| 23 | +--> |
| 24 | + |
| 25 | +# Superset Extension Architecture |
| 26 | + |
| 27 | +Apache Superset's extension architecture enables developers to enhance and customize the platform without modifying the core codebase. Inspired by the successful VS Code Extensions model, this architecture provides well-defined, versioned APIs and clear contribution points that allow the community to build upon and extend Superset's functionality. |
| 28 | + |
| 29 | +## Core Concepts |
| 30 | + |
| 31 | +### Extensions vs Plugins |
| 32 | + |
| 33 | +We use the term "extensions" rather than "plugins" to better convey the idea of enhancing and expanding Superset's core capabilities in a modular and integrated way. Extensions can add new features, modify existing behavior, and integrate deeply with the host application through well-defined APIs. |
| 34 | + |
| 35 | +### Lean Core Philosophy |
| 36 | + |
| 37 | +Superset's core remains minimal, with many features delegated to extensions. Built-in features are implemented using the same APIs available to external extension authors, ensuring consistency and validating the extension architecture through real-world usage. |
| 38 | + |
| 39 | +## Architecture Overview |
| 40 | + |
| 41 | +The extension architecture consists of several key components: |
| 42 | + |
| 43 | +### Core Packages |
| 44 | + |
| 45 | +#### @apache-superset/core (Frontend) |
| 46 | +Provides essential building blocks for extensions: |
| 47 | +- Shared UI components |
| 48 | +- Utility functions |
| 49 | +- Type definitions |
| 50 | +- Frontend APIs for interacting with the host |
| 51 | + |
| 52 | +#### apache-superset-core (Backend) |
| 53 | +Exposes backend functionality: |
| 54 | +- Database access APIs |
| 55 | +- Security models |
| 56 | +- REST API extensions |
| 57 | +- SQLAlchemy models and utilities |
| 58 | + |
| 59 | +### Extension CLI |
| 60 | + |
| 61 | +The `apache-superset-extensions-cli` package provides commands for: |
| 62 | +- Scaffolding new extension projects |
| 63 | +- Building and bundling extensions |
| 64 | +- Development workflows with hot-reload |
| 65 | +- Packaging extensions for distribution |
| 66 | + |
| 67 | +### Host Application |
| 68 | + |
| 69 | +Superset acts as the host, providing: |
| 70 | +- Extension registration and management |
| 71 | +- Dynamic loading of extension assets |
| 72 | +- API implementation for extensions |
| 73 | +- Lifecycle management (activation/deactivation) |
| 74 | + |
| 75 | +## Extension Points |
| 76 | + |
| 77 | +Extensions can contribute to various parts of Superset: |
| 78 | + |
| 79 | +### SQL Lab Extensions |
| 80 | +- Custom panels (left, right, bottom) |
| 81 | +- Editor enhancements |
| 82 | +- Query processors |
| 83 | +- Autocomplete providers |
| 84 | +- Execution plan visualizers |
| 85 | + |
| 86 | +### Dashboard Extensions (Future) |
| 87 | +- Custom widget types |
| 88 | +- Filter components |
| 89 | +- Interaction handlers |
| 90 | + |
| 91 | +### Chart Extensions (Future) |
| 92 | +- New visualization types |
| 93 | +- Data transformers |
| 94 | +- Export formats |
| 95 | + |
| 96 | +## Technical Foundation |
| 97 | + |
| 98 | +### Module Federation |
| 99 | + |
| 100 | +Frontend extensions leverage Webpack Module Federation for dynamic loading: |
| 101 | +- Extensions are built independently |
| 102 | +- Dependencies are shared with the host |
| 103 | +- No rebuild of Superset required |
| 104 | +- Runtime loading of extension assets |
| 105 | + |
| 106 | +### API Versioning |
| 107 | + |
| 108 | +All public APIs follow semantic versioning: |
| 109 | +- Breaking changes require major version bumps |
| 110 | +- Extensions declare compatibility requirements |
| 111 | +- Backward compatibility maintained within major versions |
| 112 | + |
| 113 | +### Security Model |
| 114 | + |
| 115 | +- Extensions disabled by default (require `ENABLE_EXTENSIONS` flag) |
| 116 | +- Built-in extensions follow same security standards as core |
| 117 | +- External extensions run in same context as host (sandboxing planned) |
| 118 | +- Administrators responsible for vetting third-party extensions |
| 119 | + |
| 120 | +## Development Workflow |
| 121 | + |
| 122 | +1. **Initialize**: Use CLI to scaffold new extension |
| 123 | +2. **Develop**: Work with hot-reload in development mode |
| 124 | +3. **Build**: Bundle frontend and backend assets |
| 125 | +4. **Package**: Create `.supx` distribution file |
| 126 | +5. **Deploy**: Upload through API or management UI |
| 127 | + |
| 128 | +## Example: Dataset References Extension |
| 129 | + |
| 130 | +A practical example demonstrating the architecture: |
| 131 | + |
| 132 | +```typescript |
| 133 | +// Frontend activation |
| 134 | +export function activate(context) { |
| 135 | + // Register a new SQL Lab panel |
| 136 | + const panel = core.registerView('dataset_references.main', |
| 137 | + <DatasetReferencesPanel /> |
| 138 | + ); |
| 139 | + |
| 140 | + // Listen to query changes |
| 141 | + const listener = sqlLab.onDidQueryRun(editor => { |
| 142 | + // Analyze query and update panel |
| 143 | + }); |
| 144 | + |
| 145 | + // Cleanup on deactivation |
| 146 | + context.subscriptions.push(panel, listener); |
| 147 | +} |
| 148 | +``` |
| 149 | + |
| 150 | +```python |
| 151 | +# Backend API extension |
| 152 | +from superset_core.api import rest_api |
| 153 | +from .api import DatasetReferencesAPI |
| 154 | + |
| 155 | +# Register custom REST endpoints |
| 156 | +rest_api.add_extension_api(DatasetReferencesAPI) |
| 157 | +``` |
| 158 | + |
| 159 | +## Best Practices |
| 160 | + |
| 161 | +### Extension Design |
| 162 | +- Keep extensions focused on specific functionality |
| 163 | +- Use versioned APIs for stability |
| 164 | +- Handle cleanup properly on deactivation |
| 165 | +- Follow Superset's coding standards |
| 166 | + |
| 167 | +### Performance |
| 168 | +- Lazy load assets when possible |
| 169 | +- Minimize bundle sizes |
| 170 | +- Share dependencies with host |
| 171 | +- Cache expensive operations |
| 172 | + |
| 173 | +### Compatibility |
| 174 | +- Declare API version requirements |
| 175 | +- Test across Superset versions |
| 176 | +- Provide migration guides for breaking changes |
| 177 | +- Document compatibility clearly |
| 178 | + |
| 179 | +## Future Roadmap |
| 180 | + |
| 181 | +Planned enhancements include: |
| 182 | +- JavaScript sandboxing for untrusted extensions |
| 183 | +- Extension marketplace and registry |
| 184 | +- Inter-extension communication |
| 185 | +- Advanced theming capabilities |
| 186 | +- Backend hot-reload without restart |
| 187 | + |
| 188 | +## Getting Started |
| 189 | + |
| 190 | +Ready to build your first extension? Check out: |
| 191 | +- [Extension Development Guide](/developer_portal/get-started/your-first-extension) |
| 192 | +- [API Reference](/developer_portal/api/frontend) |
| 193 | +- [CLI Documentation](/developer_portal/cli/overview) |
| 194 | +- [Example Extensions](/developer_portal/examples) |
0 commit comments