data-primals-engine 1.7.1 → 1.7.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +9 -9
- package/client/package-lock.json +8430 -8121
- package/client/package.json +7 -4
- package/client/src/APIInfo.jsx +1 -1
- package/client/src/App.jsx +2 -1
- package/client/src/App.scss +1635 -1626
- package/client/src/AssistantChat.jsx +2 -3
- package/client/src/CalendarView.jsx +1 -0
- package/client/src/ContentView.jsx +3 -3
- package/client/src/Dashboard.jsx +5 -2
- package/client/src/DashboardChart.jsx +1 -0
- package/client/src/DashboardFlexViewItem.jsx +1 -0
- package/client/src/DashboardHtmlViewItem.jsx +1 -0
- package/client/src/DashboardView.jsx +2 -0
- package/client/src/DataEditor.jsx +0 -1
- package/client/src/DataImporter.jsx +489 -468
- package/client/src/DataLayout.jsx +25 -23
- package/client/src/DataTable.jsx +6 -5
- package/client/src/Dialog.jsx +92 -90
- package/client/src/Dialog.scss +122 -116
- package/client/src/DisplayFlexNodeRenderer.jsx +1 -0
- package/client/src/DocumentationPageLayout.scss +1 -1
- package/client/src/FlexBuilderControls.jsx +1 -0
- package/client/src/FlexBuilderPreview.jsx +1 -1
- package/client/src/FlexNode.jsx +1 -1
- package/client/src/HistoryDialog.jsx +3 -2
- package/client/src/KPIWidget.jsx +1 -1
- package/client/src/KanbanView.jsx +1 -0
- package/client/src/ModelCreator.jsx +4 -0
- package/client/src/ModelList.jsx +1 -0
- package/client/src/PackGallery.jsx +5 -4
- package/client/src/RTETrans.jsx +1 -1
- package/client/src/RelationField.jsx +2 -0
- package/client/src/RelationSelectorWidget.jsx +2 -0
- package/client/src/RelationValue.jsx +1 -0
- package/client/src/RestoreDialog.jsx +1 -0
- package/client/src/ViewSwitcher.jsx +1 -1
- package/client/src/WorkflowEditor.jsx +3 -0
- package/client/src/contexts/CommandContext.jsx +2 -1
- package/client/src/contexts/ModelContext.jsx +3 -3
- package/client/src/hooks/data.js +1 -0
- package/client/src/hooks/useValidation.js +1 -0
- package/client/src/translations.js +24 -24
- package/client/vite.config.js +31 -30
- package/doc/AI-assistance.md +87 -63
- package/doc/Concepts.md +122 -0
- package/doc/Custom-Endpoints.md +31 -0
- package/doc/Event-system.md +13 -14
- package/doc/Home.md +33 -0
- package/doc/Modules.md +83 -0
- package/doc/Packs-gallery.md +8 -23
- package/doc/Workflows.md +32 -0
- package/doc/automation-workflows.md +141 -102
- package/doc/dashboards-kpis-charts.md +47 -49
- package/doc/data-management.md +126 -120
- package/doc/data-models.md +68 -75
- package/doc/roles-permissions.md +144 -43
- package/doc/sharding-replication.md +158 -0
- package/doc/users.md +54 -30
- package/package.json +27 -17
- package/server.js +37 -37
- package/src/ai.jobs.js +135 -0
- package/src/constants.js +560 -545
- package/src/data.js +521 -518
- package/src/email.js +157 -154
- package/src/engine.js +167 -49
- package/src/gameObject.js +6 -0
- package/src/i18n.js +0 -1
- package/src/modules/assistant/assistant.js +782 -763
- package/src/modules/assistant/constants.js +23 -16
- package/src/modules/assistant/providers.js +77 -37
- package/src/modules/auth-google/index.js +53 -50
- package/src/modules/bucket.js +346 -335
- package/src/modules/data/data.backup.js +400 -376
- package/src/modules/data/data.cluster.js +559 -0
- package/src/modules/data/data.core.js +11 -8
- package/src/modules/data/data.js +311 -311
- package/src/modules/data/data.operations.js +3666 -3555
- package/src/modules/data/data.relations.js +1 -0
- package/src/modules/data/data.replication.js +125 -0
- package/src/modules/data/data.routes.js +2206 -1879
- package/src/modules/data/data.scheduling.js +2 -1
- package/src/modules/file.js +248 -247
- package/src/modules/mongodb.js +76 -73
- package/src/modules/user.js +18 -2
- package/src/modules/worker-script-runner.js +97 -0
- package/src/modules/workflow.js +177 -52
- package/src/packs.js +5701 -5701
- package/src/providers.js +298 -297
- package/src/sso.js +91 -25
- package/test/assistant.test.js +207 -206
- package/test/cluster.test.js +221 -0
- package/test/core.test.js +0 -2
- package/test/data.integration.test.js +1425 -1416
- package/test/import_export.integration.test.js +210 -210
- package/test/replication.test.js +163 -0
- package/test/workflow.actions.integration.test.js +487 -475
- package/test/workflow.integration.test.js +332 -329
- package/doc/core-concepts.md +0 -33
package/doc/AI-assistance.md
CHANGED
|
@@ -1,93 +1,117 @@
|
|
|
1
1
|
# AI Assistance: Leverage Artificial Intelligence
|
|
2
2
|
|
|
3
|
-
`data-primals-engine`
|
|
3
|
+
The `data-primals-engine` integrates powerful generative AI capabilities directly into its core, allowing you to automate content creation, analyze data, and enrich your business processes.
|
|
4
4
|
|
|
5
5
|
## Enabling the AI Assistant
|
|
6
6
|
|
|
7
|
-
To use the AI
|
|
7
|
+
To use the AI features, you must first provide API keys for one or more supported AI providers. The engine natively supports providers like **OpenAI, Google (Gemini), DeepSeek, and Anthropic**.
|
|
8
8
|
|
|
9
9
|
You can configure your keys in two ways:
|
|
10
10
|
|
|
11
11
|
1. **Environment Variables**: Set the appropriate variable in your `.env` file. This is the recommended approach for production.
|
|
12
|
-
```env
|
|
13
|
-
# Choose one or more providers
|
|
14
|
-
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
|
|
15
|
-
GOOGLE_API_KEY=AIzaSyxxxxxxxxxxxxxxxxxxxx
|
|
16
|
-
DEEPSEEK_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
|
|
17
|
-
```
|
|
18
12
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
### 1. Data Querying and Visualization
|
|
28
|
-
|
|
29
|
-
You can ask the assistant to find, filter, and display your data. It can present the results in various formats.
|
|
30
|
-
|
|
31
|
-
- **Simple Search**:
|
|
32
|
-
> "Show me the latest 5 orders from French customers."
|
|
33
|
-
|
|
34
|
-
- **Chart Generation**: Create charts on the fly.
|
|
35
|
-
> "Create a bar chart of user sign-ups per month for the last year."
|
|
36
|
-
|
|
37
|
-
- **Custom HTML Views**: Generate sophisticated, styled views of your data using Handlebars templates.
|
|
38
|
-
> "Build a dashboard of my active projects with their status and due dates, using a modern dark theme."
|
|
39
|
-
|
|
40
|
-
### 2. Data Modification (with Confirmation)
|
|
13
|
+
```env
|
|
14
|
+
# Choose one or more providers
|
|
15
|
+
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
|
|
16
|
+
GOOGLE_API_KEY=AIzaSyxxxxxxxxxxxxxxxxxxxx
|
|
17
|
+
DEEPSEEK_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
|
|
18
|
+
ANTHROPIC_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
|
|
19
|
+
```
|
|
41
20
|
|
|
42
|
-
|
|
21
|
+
2. **`env` Model**: For user-specific keys, you can store them in the `env` model within the application. The assistant will automatically look for a key belonging to the current user.
|
|
43
22
|
|
|
44
|
-
|
|
45
|
-
> "Create a new task to 'Follow up with Client X' due tomorrow."
|
|
23
|
+
Once a key is configured, AI capabilities become available, most notably within the automation engine.
|
|
46
24
|
|
|
47
|
-
|
|
48
|
-
> "Update the status of all tickets in the 'Support' category to 'resolved'."
|
|
25
|
+
## AI in Workflows: The `GenerateAIContent` Action
|
|
49
26
|
|
|
50
|
-
-
|
|
51
|
-
> "Delete all draft products created before last month."
|
|
27
|
+
The most powerful way to use AI in `data-primals-engine` is by integrating it into your **Workflows**. The `GenerateAIContent` action type allows you to call an AI model as a step in any automated process.
|
|
52
28
|
|
|
53
|
-
|
|
29
|
+
This is perfect for tasks like:
|
|
30
|
+
- Summarizing a new support ticket.
|
|
31
|
+
- Generating a product description when a new product is added.
|
|
32
|
+
- Classifying incoming data based on its content.
|
|
33
|
+
- Translating text.
|
|
54
34
|
|
|
55
|
-
###
|
|
35
|
+
### Example: Automatically Generating a Product Description
|
|
56
36
|
|
|
57
|
-
|
|
37
|
+
Let's create a complete workflow that automatically generates an SEO description whenever a new product is added without one.
|
|
58
38
|
|
|
59
|
-
|
|
39
|
+
This workflow can be created programmatically by making the following API calls from your JavaScript code.
|
|
60
40
|
|
|
61
|
-
## How It Works: The Reasoning Loop
|
|
62
41
|
|
|
63
|
-
|
|
42
|
+
#### 1. The `workflow`
|
|
64
43
|
|
|
65
|
-
|
|
66
|
-
2. **Search Models (Internal Step)**: Its first action is always to call the `search_models` tool internally. This gives it the exact structure, field names, and types for the relevant data models. This step is crucial for preventing errors and "hallucinations."
|
|
67
|
-
3. **Formulate Action**: Based on your intent and the model structures it found, it formulates a final action, such as `search`, `generateChart`, or a `post` request.
|
|
68
|
-
4. **Execute or Confirm**:
|
|
69
|
-
- If it's a read-only action (like `search` or `generateChart`), it executes it and displays the result.
|
|
70
|
-
- If it's a write action (like `post` or `delete`), it presents the action to you for confirmation.
|
|
44
|
+
First, we define the main workflow. This document acts as a container for the steps and logic.
|
|
71
45
|
|
|
72
|
-
|
|
46
|
+
```javascript
|
|
47
|
+
await insertData("workflow", {
|
|
48
|
+
"name": "Generate Product SEO Description",
|
|
49
|
+
"description": "When a new product is created without an SEO description, this workflow uses AI to generate one based on the product's name.",
|
|
50
|
+
"startStep": { "$find": { "name": "Generate and Update Description" } }
|
|
51
|
+
});
|
|
52
|
+
```
|
|
73
53
|
|
|
74
|
-
|
|
54
|
+
#### 2. The `workflowAction` documents
|
|
75
55
|
|
|
76
|
-
|
|
77
|
-
- Summarizing a new support ticket.
|
|
78
|
-
- Generating a product description when a new product is added.
|
|
79
|
-
- Classifying incoming data based on its content.
|
|
80
|
-
- Translating text.
|
|
56
|
+
Next, we define the individual actions that will be performed. We need two actions: one to generate the content with AI, and another to update the product with that content. We use `insertData` to create both in a single call.
|
|
81
57
|
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
{
|
|
85
|
-
"name": "
|
|
58
|
+
```javascript
|
|
59
|
+
await insertData("workflowAction", [
|
|
60
|
+
{
|
|
61
|
+
"name": "Generate SEO Content",
|
|
86
62
|
"type": "GenerateAIContent",
|
|
87
63
|
"aiProvider": "OpenAI",
|
|
88
|
-
"aiModel": "gpt-
|
|
89
|
-
"prompt": "
|
|
90
|
-
}
|
|
64
|
+
"aiModel": "gpt-4o-mini",
|
|
65
|
+
"prompt": "Write a short, engaging, and SEO-optimized product description (30-40 words) for the following product: '{triggerData.name}'. Return only the description text, without any introductory or concluding phrases."
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"name": "Update Product with AI Content",
|
|
69
|
+
"type": "UpdateData",
|
|
70
|
+
"targetModel": "product",
|
|
71
|
+
"targetSelector": { "_id": "{triggerData._id}" },
|
|
72
|
+
"fieldsToUpdate": { "seoDescription": "{context.aiContent}" }
|
|
73
|
+
}
|
|
74
|
+
]);
|
|
75
|
+
```
|
|
76
|
+
> **Note**: The `targetSelector` and `fieldsToUpdate` use placeholders. `{triggerData._id}` refers to the ID of the product that started the workflow, and `{context.aiContent}` refers to the text generated by the previous AI action.
|
|
77
|
+
|
|
78
|
+
#### 3. The `workflowStep`
|
|
79
|
+
|
|
80
|
+
Now, we create a step that groups our actions together. A workflow can have multiple steps that execute in sequence. For this simple case, we only need one, which we create with `insertData`.
|
|
81
|
+
|
|
82
|
+
```javascript
|
|
83
|
+
await insertData("workflowStep", {
|
|
84
|
+
"name": "Generate and Update Description",
|
|
85
|
+
"workflow": { "$find": { "name": "Generate Product SEO Description" } },
|
|
86
|
+
"actions": [
|
|
87
|
+
{ "$find": { "name": "Generate SEO Content" } },
|
|
88
|
+
{ "$find": { "name": "Update Product with AI Content" } }
|
|
89
|
+
],
|
|
90
|
+
"isTerminal": true
|
|
91
|
+
});
|
|
91
92
|
```
|
|
92
93
|
|
|
94
|
+
#### 4. The `workflowTrigger`
|
|
95
|
+
|
|
96
|
+
Finally, we define the trigger that will start the workflow. This trigger will listen for new documents being added (`DataAdded`) to the `product` model. It also includes a `dataFilter` to ensure it only runs if the `seoDescription` field is empty. We create it with `insertData`.
|
|
97
|
+
|
|
98
|
+
```javascript
|
|
99
|
+
await insertData("workflowTrigger", {
|
|
100
|
+
"name": "On New Product Added without SEO Description",
|
|
101
|
+
"workflow": { "$find": { "name": "Generate Product SEO Description" } },
|
|
102
|
+
"type": "manual",
|
|
103
|
+
"onEvent": "DataAdded",
|
|
104
|
+
"targetModel": "product",
|
|
105
|
+
"dataFilter": {
|
|
106
|
+
"$or": [
|
|
107
|
+
{ "seoDescription": { "$exists": false } },
|
|
108
|
+
{ "seoDescription": "" }
|
|
109
|
+
]
|
|
110
|
+
},
|
|
111
|
+
"isActive": true
|
|
112
|
+
});
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
With these four API calls, your automated AI content generation workflow is now active. Any new product created without an SEO description will automatically have one generated and saved.
|
|
116
|
+
|
|
93
117
|
This integration of AI both as an interactive assistant and as an automation component makes `data-primals-engine` a powerful platform for building intelligent applications.
|
package/doc/Concepts.md
ADDED
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
# Fundamental Concepts
|
|
2
|
+
|
|
3
|
+
`data-primals-engine` is built on a set of core concepts designed to provide maximum flexibility and power. Understanding these concepts is essential to getting the most out of the platform.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. [Models](data-models)
|
|
8
|
+
|
|
9
|
+
A **model** represents a data entity in your application, similar to a table in an SQL database or a collection in MongoDB. Each model has a set of fields that define the structure of the data it contains.
|
|
10
|
+
|
|
11
|
+
- **Visual Definition**: Models can be created and modified directly from the user interface, without requiring manual database migrations.
|
|
12
|
+
|
|
13
|
+
- **Flexibility**: A model's structure can be updated at any time.
|
|
14
|
+
### Model Generation
|
|
15
|
+
Models are the way to handle structured data. They organize data and they can be declared in JSON.
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"name": "product",
|
|
20
|
+
"description": "E-commerce product schema",
|
|
21
|
+
"fields": [
|
|
22
|
+
{ "name": "name", "type": "string", "required": true },
|
|
23
|
+
{ "name": "price", "type": "number", "required": true },
|
|
24
|
+
{ "name": "stock", "type": "number", "default": 0 },
|
|
25
|
+
{ "name": "category", "type": "relation", "relation": "taxonomy",
|
|
26
|
+
"relationFilter": { "$eq": ["$type", "category"] }
|
|
27
|
+
},
|
|
28
|
+
{ "name": "tags", "type": "relation", "relation": "taxonomy", "multiple": true,
|
|
29
|
+
"relationFilter": { "$eq": ["$type", "keyword"] }
|
|
30
|
+
}
|
|
31
|
+
]
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
#### Dynamic Index Management
|
|
36
|
+
|
|
37
|
+
The engine features a sophisticated system for managing database indexes directly from the model editor UI. This eliminates the need for manual database administration or migration scripts for indexing, significantly speeding up development and reducing errors.
|
|
38
|
+
|
|
39
|
+
Indexes are created, updated, and removed automatically when you save a model's structure. All created indexes are **partial indexes**, meaning they only include documents for the specific model and user, which optimizes storage and performance.
|
|
40
|
+
|
|
41
|
+
You can enable indexing on any field by checking the `index` box in the model editor and choosing one of the following types:
|
|
42
|
+
|
|
43
|
+
| Index Type | `indexType` | Use Case & Behavior -|
|
|
44
|
+
|-----------------|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
45
|
+
| **Regular** | `regular` | **Purpose**: The standard index for most use cases. It dramatically speeds up queries, sorting, and filtering on a specific field. <br/> **Behavior**: Creates a standard ascending B-tree index on a single field. This is the default and most common index type. -|
|
|
46
|
+
| **Text Search** | `text` | **Purpose**: Enables powerful, language-aware full-text search across one or more fields. It's ideal for implementing search bars that need to query descriptions, titles, and other text-heavy content. <br/> **Behavior**: Creates a single, special **compound `text` index** for the entire model. All fields marked with `indexType: 'text'` are included in this single index. This allows you to use MongoDB's `$text` operator in your search queries. -|
|
|
47
|
+
| **Geospatial** | `2dsphere` | **Purpose**: Essential for location-based queries. It allows you to efficiently find documents within a certain radius, within a polygon, or sorted by distance. <br/> **Behavior**: Creates a `2dsphere` index on a single field. This index type should be used exclusively on fields of type `geolocation` which store data in GeoJSON format (e.g., `{ "type": "Point", "coordinates": [ -73.97, 40.77 ] }`). |
|
|
48
|
+
|
|
49
|
+
### Model constraints
|
|
50
|
+
```javascript
|
|
51
|
+
{
|
|
52
|
+
"name": "modelName",
|
|
53
|
+
"fields": [
|
|
54
|
+
{ "name": "fieldName1", .... },
|
|
55
|
+
{ "name": "fieldName2", .... }
|
|
56
|
+
],
|
|
57
|
+
"constraints": [
|
|
58
|
+
// uniqueness
|
|
59
|
+
{ "name": "uniqueConstraint", type: "unique", keys: ["fieldName1", "fieldName2"] }
|
|
60
|
+
]
|
|
61
|
+
}
|
|
62
|
+
```
|
|
63
|
+
### Other model features
|
|
64
|
+
- Handles up to 1500 direct relations per document by default (can be customized). For larger datasets, use intermediate collections or maxRelationsPerData constant.
|
|
65
|
+
- Anonymizable fields (encrypted for API users)
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
## 2. [Fields](data-models)
|
|
69
|
+
|
|
70
|
+
**Fields** are the attributes that make up a model. `data-primals-engine` supports a wide variety of field types to cover all needs:
|
|
71
|
+
|
|
72
|
+
### Fields types
|
|
73
|
+
|
|
74
|
+
| Type | Description | Properties/Notes |
|
|
75
|
+
|:------------|:------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|
|
|
76
|
+
| string | Character string. | minLength, maxLength |
|
|
77
|
+
| string_t | International character string ID. | same as string, translated in { key, value } |
|
|
78
|
+
| number | Numeric value (integer or float). | min, max |
|
|
79
|
+
| boolean | Boolean value (true/false). | – |
|
|
80
|
+
| date | Stores a ISO date. | – |
|
|
81
|
+
| datetime | Stores an ISO date and time. | – |
|
|
82
|
+
| richtext | Rich text field (HTML) for WYSIWYG editors. | |
|
|
83
|
+
| richtext_t | International rich text field (HTML) for WYSIWYG editors. | i18n |
|
|
84
|
+
| email | String validated as an email address. | – |
|
|
85
|
+
| password | String that will be automatically hashed. | – |
|
|
86
|
+
| enum | Allows selecting a value from a predefined list. | items: ["value1", "value2"] |
|
|
87
|
+
| relation | Creates a link to a document in another model. | relation: "target_model_name", multiple: true/false |
|
|
88
|
+
| file | For uploading a file (stored on S3 if configured). | allowedTypes:['image/jpeg', 'image/png', 'image/bmp'], maxSize: 1024*1000 |
|
|
89
|
+
| image | Specialized file type for images, with preview. | – |
|
|
90
|
+
| array | Stores a list of values. | itemsType: 'enum' // any type except relations |
|
|
91
|
+
| object | Stores a nested JSON object. – | |
|
|
92
|
+
| code | Stores language="*" as string, stores language="json" as arbitrary JSON structure. | language="json" conditionBuilder=true |
|
|
93
|
+
| color | Stores an hexadecimal value of an RGB color | '#FF0000' |
|
|
94
|
+
| model | Stores a model by name | – |
|
|
95
|
+
| modelField | Stores a model field path | – |
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
Each field can have specific validation rules to guarantee data integrity.
|
|
99
|
+
|
|
100
|
+
## 3. [Permissions (RBAC)](roles-permissions)
|
|
101
|
+
|
|
102
|
+
Access management is handled by a **Role-Based Access Control (RBAC)** system.
|
|
103
|
+
|
|
104
|
+
- **Roles**: You can define roles (e.g., `Admin`, `Editor`, `Visitor`).
|
|
105
|
+
|
|
106
|
+
- **Granular Permissions**: For each model, you can assign CRUD (Create, Read, Update, Delete) permissions to each role. For example, an `Editor` can create and modify articles, but not delete them.
|
|
107
|
+
|
|
108
|
+
This system allows for granular security of access to your data.
|
|
109
|
+
|
|
110
|
+
## 4. [User management](users)
|
|
111
|
+
|
|
112
|
+
The engine includes a robust authentication system based on **JWT (JSON Web Tokens)**.
|
|
113
|
+
|
|
114
|
+
- ****: A `User` model is typically used to manage user accounts.
|
|
115
|
+
|
|
116
|
+
- **Security**: `JWT_SECRET` ensures that tokens cannot be forged.
|
|
117
|
+
|
|
118
|
+
## 5. Advanced Data Management
|
|
119
|
+
|
|
120
|
+
- **Complex Queries**: Leverage the power of MongoDB to perform complex queries and aggregations on your data.
|
|
121
|
+
|
|
122
|
+
- **Automatic Auditing**: The engine can automatically maintain a history of changes for each record, allowing you to know who did what and when.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Custom API Endpoints
|
|
2
|
+
|
|
3
|
+
While `data-primals-engine` provides a full REST API for CRUD operations on your models, you may sometimes need to create API endpoints with specific business logic.
|
|
4
|
+
|
|
5
|
+
Custom API endpoints allow you to extend the engine's native API in a secure and controlled manner.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Why Create a Custom API Endpoint?
|
|
10
|
+
|
|
11
|
+
- To execute complex logic that goes beyond simple CRUD operations (e.g., `POST /api/orders/{id}/processPayment`).
|
|
12
|
+
|
|
13
|
+
- To aggregate data from multiple models into a single response.
|
|
14
|
+
|
|
15
|
+
- To integrate with external services.
|
|
16
|
+
|
|
17
|
+
## Creation and Configuration
|
|
18
|
+
|
|
19
|
+
Custom API endpoints can be created directly from the administration interface. During creation, you configure the following:
|
|
20
|
+
|
|
21
|
+
- **HTTP Route**: The URL path (e.g., `/my-custom-action`).
|
|
22
|
+
|
|
23
|
+
- **HTTP Method**: `GET`, `POST`, `PUT`, `DELETE`, etc.
|
|
24
|
+
|
|
25
|
+
- **Permissions**: Which role is authorized to call this API point.
|
|
26
|
+
|
|
27
|
+
- **Execution Code**: You write your logic in **JavaScript (Node.js)** directly in a secure (sandbox) environment.
|
|
28
|
+
|
|
29
|
+
## Secure Execution Environment
|
|
30
|
+
|
|
31
|
+
The code you write for a custom API point runs in an isolated environment. You have controlled access to engine features (such as `searchData`, `insertData`) and certain Node.js libraries, which ensures that your custom code cannot compromise the security or stability of the main application.
|
package/doc/Event-system.md
CHANGED
|
@@ -63,17 +63,16 @@ When multiple listeners are registered for an event, their return values are mer
|
|
|
63
63
|
|
|
64
64
|
Here is a list of the most important events you can listen to:
|
|
65
65
|
|
|
66
|
-
| Event
|
|
67
|
-
|
|
68
|
-
| `OnServerStart` | Triggered once the HTTP server is started and listening.
|
|
69
|
-
| `
|
|
70
|
-
| `
|
|
71
|
-
| `
|
|
72
|
-
| `
|
|
73
|
-
| `
|
|
74
|
-
| `
|
|
75
|
-
| `
|
|
76
|
-
| `
|
|
77
|
-
| `
|
|
78
|
-
| `
|
|
79
|
-
| `OnSystemPrompt` | Triggered to override the AI assistant's system prompt. | User | `handleChatRequest` | `user` |
|
|
66
|
+
| Event | Description | Scope | Triggered by | Arguments (Payload) |
|
|
67
|
+
|:-----------------|:------------------------------------------------------------------------|:-------|:-------------------------|:---------------------------------------------------------------------|
|
|
68
|
+
| `OnServerStart` | Triggered once the HTTP server is started and listening. | System | `engine.start()` | `engine` |
|
|
69
|
+
| `OnModelsLoaded` | Triggered after the initial models are loaded at startup. | System | `setupInitialModels()` | `engine`, `dbModels` |
|
|
70
|
+
| `OnModelEdited` | Triggered after a model definition has been modified. | System | `editModel()` | `newModel` |
|
|
71
|
+
| `OnDataAdded` | Triggered after new data has been inserted. | System | `insertData()` | `engine`, `insertedDocs` |
|
|
72
|
+
| `OnDataEdited` | Triggered after data has been edited. | System | `editData()` / `patchData()` | `engine`, `{modelName, before, after}` |
|
|
73
|
+
| `OnDataDeleted` | Triggered just after data is actually deleted. | System | `deleteData()` | `engine`, `{model, filter}` |
|
|
74
|
+
| `OnDataSearched` | Triggered after a data search. | System | `searchData()` | `engine`, `{data, count}` |
|
|
75
|
+
| `OnDataInsert` | Triggered just before data insertion. Allows modifying the data. | System | internal | `data` |
|
|
76
|
+
| `OnDataValidate` | Triggered to override validation checks. | System | internal | `value`, `field`, `data` |
|
|
77
|
+
| `OnChatAction` | Triggered when an AI assistant decides on an action. | User | `handleChatRequest` | `action`, `params`, `parsedResponse`, `command`, `llmOptions`, `user`, `reqParams` |
|
|
78
|
+
| `OnSystemPrompt` | Triggered to override the AI assistant's system prompt. | User | `handleChatRequest` | `user` |
|
package/doc/Home.md
ADDED
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Welcome to the data-primals-engine Wiki! 👋
|
|
2
|
+
|
|
3
|
+
This wiki is your central guide to using, integrating, and extending the platform.
|
|
4
|
+
|
|
5
|
+
## 🧭 Explore the Platform
|
|
6
|
+
Discover the core features to get started building and managing your data.
|
|
7
|
+
Link to the official documentation: https://data.primals.net/en/documentation/
|
|
8
|
+
|
|
9
|
+
- 🧠 [Core Concepts](Concepts): Explore the fundamentals of data modeling.
|
|
10
|
+
- 🔌 [Custom API Endpoints](custom-api-endpoints): Create dynamic HTTP routes directly from the backend.
|
|
11
|
+
- 🏗️ [Data Models](data-models): Structure your information.
|
|
12
|
+
- 🗃️ [Data Management](data-management): Create, read, update, and delete your entries.
|
|
13
|
+
- 📈 [Dashboards, KPIs, and Charts](dashboards-kpis-charts): Track your key metrics.
|
|
14
|
+
- 👥 [Users](users): Manage access to the platform.
|
|
15
|
+
- 🔐 [Roles and Permissions](roles-permissions): Define who can see and do what.
|
|
16
|
+
- ⚙️ [Automation with Workflows](automation-workflows): Create automated processes.
|
|
17
|
+
- 🎁 [Pack Gallery](Packs-gallery): Discover ready-to-use configurations.
|
|
18
|
+
- 🤖 [AI Assistance](AI-assistance): Leverage artificial intelligence.
|
|
19
|
+
|
|
20
|
+
## 🧩 Extend Capabilities
|
|
21
|
+
Go further by developing your own features and business logic.
|
|
22
|
+
|
|
23
|
+
- ⚡ [Event System](Event-system): React to events in real time.
|
|
24
|
+
- 🧠 [Advanced Workflows](Advanced-workflows): Create complex logic with custom scripts.
|
|
25
|
+
- 📦 [Modules](Modules): Package and share your developments.
|
|
26
|
+
- 🚀 [Sharding & Replication](sharding-replication): Scale horizontally and ensure high availability.
|
|
27
|
+
- ❤️ [Contribute to the project (CONTRIBUTING.md)](https://github.com/anonympins/data-primals-engine/blob/main/CONTRIBUTING.md): Join the developer community.
|
|
28
|
+
|
|
29
|
+
## 💻 For Developers
|
|
30
|
+
Essential tools for a seamless development experience.
|
|
31
|
+
|
|
32
|
+
- 📖 [Explore the API with Swagger](https://data.primals.net/api-docs/): Test API access points directly from your browser.
|
|
33
|
+
- 📮 [Postman Collection](https://data.primals.net/doc/API.postman_collection.json): Import our collection to start querying in just a few clicks.
|
package/doc/Modules.md
ADDED
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
# Modules: Packaging and Extending Features
|
|
2
|
+
|
|
3
|
+
The `data-primals-engine` is designed to be modular, allowing you to enable, disable, or create new features in a clean and organized way. A **Module** is a self-contained unit of functionality that plugs into the core engine at startup.
|
|
4
|
+
|
|
5
|
+
This approach keeps the core lightweight while allowing for powerful extensions like SSO authentication, payment gateway integrations, or custom API functionalities.
|
|
6
|
+
|
|
7
|
+
## How Modules Work
|
|
8
|
+
|
|
9
|
+
1. **Discovery**: The engine looks for modules in the `src/modules/` directory.
|
|
10
|
+
2. **Activation**: You specify which modules to activate using the `Config` object.
|
|
11
|
+
3. **Initialization**: For each active module, the engine calls its exported `onInit(engine)` function, passing the main engine instance. This is the module's entry point to interact with the system.
|
|
12
|
+
|
|
13
|
+
## Enabling an Existing Module
|
|
14
|
+
|
|
15
|
+
The engine comes with several built-in modules, such as authentication providers. To enable one, you add its name to the `modules` array in your configuration **before** initializing the engine.
|
|
16
|
+
|
|
17
|
+
**Example: Enabling Google SSO and the Assistant**
|
|
18
|
+
|
|
19
|
+
```javascript
|
|
20
|
+
import { Engine, Config } from 'data-primals-engine';
|
|
21
|
+
|
|
22
|
+
// Add modules to the list of modules to be loaded
|
|
23
|
+
Config.Set("modules", ["auth-google", "assistant"]);
|
|
24
|
+
|
|
25
|
+
const app = express();
|
|
26
|
+
const engine = await Engine.Create({ app });
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
You may also need to install peer dependencies (`npm install passport-google-oauth20`) and set environment variables (`GOOGLE_CLIENT_ID`, etc.) as required by the module.
|
|
30
|
+
|
|
31
|
+
## Creating a New Module
|
|
32
|
+
|
|
33
|
+
Creating a module is straightforward. It only requires a JavaScript file in the `src/modules/my-module/` directory that exports an `async` function named `onInit`.
|
|
34
|
+
|
|
35
|
+
### Step 1: Create the Module File
|
|
36
|
+
|
|
37
|
+
Create a new file, for example: `src/modules/greeter/greeter.js`
|
|
38
|
+
|
|
39
|
+
### Step 2: Write the `onInit` Function
|
|
40
|
+
|
|
41
|
+
In `greeter.js`, write your initialization logic. The `onInit` function gives you access to the entire engine.
|
|
42
|
+
|
|
43
|
+
```javascript
|
|
44
|
+
// src/modules/greeter/greeter.js
|
|
45
|
+
|
|
46
|
+
export async function onInit(engine) {
|
|
47
|
+
// 1. Get components from the engine
|
|
48
|
+
const logger = engine.getComponent('Logger');
|
|
49
|
+
const Event = engine.getComponent('Event');
|
|
50
|
+
|
|
51
|
+
// 2. Register a new API endpoint
|
|
52
|
+
engine.get('/api/greet/:name', (req, res) => {
|
|
53
|
+
const { name } = req.params;
|
|
54
|
+
res.json({ message: `Hello, ${name}! Welcome to our custom module.` });
|
|
55
|
+
});
|
|
56
|
+
|
|
57
|
+
// 3. Listen to a core event
|
|
58
|
+
Event.Listen('OnDataAdded', (engine, insertedDocs) => {
|
|
59
|
+
if (insertedDocs?.[0]._model === 'user') {
|
|
60
|
+
logger.info(`A new user has signed up: ${insertedDocs[0].username}`);
|
|
61
|
+
}
|
|
62
|
+
}, 'event', 'system');
|
|
63
|
+
|
|
64
|
+
// 4. Log that the module has been loaded
|
|
65
|
+
logger.info("Module 'greeter' loaded successfully.");
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### Step 3: Enable Your New Module
|
|
70
|
+
|
|
71
|
+
In your main server file, enable your module via the `Config` object.
|
|
72
|
+
|
|
73
|
+
```javascript
|
|
74
|
+
Config.Set("modules", ["greeter"]); // Add your module's folder name
|
|
75
|
+
|
|
76
|
+
const engine = await Engine.Create({ app });
|
|
77
|
+
// When the server starts, you will see "Module 'greeter' loaded successfully." in your logs.
|
|
78
|
+
// You can now access http://localhost:7633/api/greet/World
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
Modules are the preferred way to build reusable and maintainable extensions for `data-primals-engine`.
|
|
82
|
+
|
|
83
|
+
**[Next: Sharding / Replication](sharding-replication)**
|