You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/developer_portal/extensions/interacting-with-host.md
+25-16Lines changed: 25 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,6 +26,8 @@ under the License.
26
26
27
27
Extensions interact with Superset through well-defined, versioned APIs provided by the `@apache-superset/core` (frontend) and `apache-superset-core` (backend) packages. These APIs are designed to be stable, discoverable, and consistent for both built-in and external extensions.
28
28
29
+
**Note**: The `superset_core.api` module provides abstract classes that are replaced with concrete implementations via dependency injection when Superset initializes. This allows extensions to use the same interfaces as the host application.
30
+
29
31
**Frontend APIs** (via `@apache-superset/core)`:
30
32
31
33
The frontend extension APIs in Superset are organized into logical namespaces such as `authentication`, `commands`, `extensions`, `sqlLab`, and others. Each namespace groups related functionality, making it easy for extension authors to discover and use the APIs relevant to their needs. For example, the `sqlLab` namespace provides events and methods specific to SQL Lab, allowing extensions to react to user actions and interact with the SQL Lab environment:
@@ -90,31 +92,38 @@ Backend APIs follow a similar pattern, providing access to Superset's models, se
90
92
Extension endpoints are registered under a dedicated `/extensions` namespace to avoid conflicting with built-in endpoints and also because they don't share the same version constraints. By grouping all extension endpoints under `/extensions`, Superset establishes a clear boundary between core and extension functionality, making it easier to manage, document, and secure both types of APIs.
91
93
92
94
```python
93
-
from superset_core.api import rest_api, models, query
95
+
from superset_core.api.models import Database, get_session
96
+
from superset_core.api.daos import DatabaseDAO
97
+
from superset_core.api.rest_api import add_extension_api
94
98
from .api import DatasetReferencesAPI
95
99
96
100
# Register a new extension REST API
97
-
rest_api.add_extension_api(DatasetReferencesAPI)
101
+
add_extension_api(DatasetReferencesAPI)
102
+
103
+
# Fetch Superset entities via the DAO to apply base filters that filter out entities
104
+
# that the user doesn't have access to
105
+
databases = DatabaseDAO.find_all()
98
106
99
-
# Access Superset models with simple queries that filter out entities that
100
-
# the user doesn't have access to
101
-
databases = models.get_databases(id=database_id)
107
+
# ..or apply simple filters on top of base filters
Copy file name to clipboardExpand all lines: docs/docs/contributing/howtos.mdx
+50Lines changed: 50 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -166,6 +166,56 @@ server:
166
166
npm run dev-server
167
167
```
168
168
169
+
#### Deploying your visualization plugin
170
+
171
+
Once your plugin is complete, you will need to deploy it to your superset instance.
172
+
173
+
This step assumes you are running your own Docker image as described [here](https://superset.apache.org/docs/installation/docker-builds/#building-your-own-production-docker-image).
174
+
Instructions may vary for other kinds of deployments.
175
+
176
+
If you have your own Superset Docker image, the first line is most likely:
177
+
`FROM apache/superset:latest` or something similar. You will need to compile
178
+
your own `"lean"` image and replace this FROM line with your own image.
179
+
180
+
1. Publish your chart plugin to npm: it makes the build process simpler.
181
+
182
+
Note: if your chart is not published to npm, then in the docker build below, you will need
183
+
to edit the default Dockerfile to copy your plugin source code to the appropriate
184
+
location in the container build environment.
185
+
186
+
2. Install your chart in the frontend with `npm i <your_chart_package>`.
187
+
3. Start with a base superset release.
188
+
189
+
```bash
190
+
git checkout tags/X.0.0
191
+
```
192
+
193
+
4. Install your chart with the instructions you followed during development.
194
+
5. Navigate to the root of your superset directory.
195
+
6. Run `docker build -t apache/superset:mychart --target lean .`
196
+
7. Rebuild your production container using `FROM apache/superset:mychart`.
197
+
198
+
This will create a new productized superset container with your new chart compiled in.
199
+
Then you can recreate your custom production container based on a superset built with your chart.
200
+
201
+
##### Troubleshooting
202
+
203
+
204
+
- If you get the following NPM error:
205
+
206
+
```
207
+
npm error `npm ci` can only install packages when your package.json and package-lock.json
208
+
```
209
+
210
+
It's because your local nodejs/npm version is different than the one being used inside docker.
211
+
212
+
You can resolve this by running npm install with the same version used by the container build process
213
+
214
+
Replace XYZ in the following command with the node tag used in the Dockerfile (search for"node:"in the Dockerfile to find the tag).
0 commit comments