WASM Plugins
Collabase features a native WebAssembly (WASM) plugin engine that allows you to securely extend the core backend. Unlike Frontend SDK Apps which run visually in an iFrame, WASM plugins run completely headless on your server. They interface directly with the Collabase backend engine via a high-performance, strictly controlled execution sandbox.Why WebAssembly?
- Sandboxed Execution: Plugins cannot crash the main Node.js event loop or application thread. Memory leaks, infinite loops, or segmentation faults inside the plugin are securely isolated.
- Zero Overhead Background Processing: Ideal for listening to system events (e.g., synchronously mutating a task payload before it saves) without the latency and network overhead of traditional HTTP webhooks.
- Polyglot Freedom: Write your backend logic in AssemblyScript, Rust, Go, or C/C++, and compile it down to a standard
.wasmbinary.
The Sandbox Environment
When the Collabase engine executes a WASM plugin, it runs within strict boundaries enforced by the host:memoryLimit: Configurable per plugin (default 64MB).timeout: Configurable execution time limit to prevent CPU monopolization (default 5000ms).
Hook Points
WASM Plugins are triggered by “Hook Points.” A Hook Point is a subscription to a system event or an interception path within the main backend architecture. Define your hook points in your plugin’s metadata manifest:Available Hook Points
Below is the list of hooks currently exposed to the WASM engine:| Hook | Payload Description | Typical Developer Use Case |
|---|---|---|
task:created | Full Task object. | Automatic tagging, custom routing, or strict validation upon creation. |
task:updated | Task object and changedFields. | Auditing specific status transitions or computing derived states. |
task:deleted | taskId string. | Triggering cleanup jobs in related external system databases. |
page:created | Page object (excluding MDX body). | Initiating external approval workflows for new documentation. |
page:updated | Page object and diff AST. | Tracking stale content or automatically triggering translation tasks. |
page:deleted | pageId string. | Archiving logic. |
user:created | User profile object. | Provisioning the user automatically in external LDAP or SCIM integrations. |
project:created | Project object. | Bootstrapping default folders, task queues, or sprint schedules for new projects. |
automation:custom_node | Node context, params, and variables. | Executing highly specialized, memory-intensive logic required by an automation flowchart. |
Host Functions
The engine provides specific “Host Functions” that bridge your isolated WASM sandbox to the underlying Collabase platform APIs.Context and Logging
The most important host function iscollabase:log. This allows your plugin to stream execution logs directly to the Admin Dashboard’s live log viewer.
AssemblyScript Example:
Compiling Your Plugin
Depending on your language of choice, compile your source code to thewasm32-unknown-unknown or equivalent target.
Write Logic
Implement your logic using the exposed Collabase host functions and your preferred language.
Installing and Updating
Once your.wasm binary is compiled, you must deploy it to the Collabase instance.
Via the Admin Interface
Reviewing Live Execution Logs
In the WASM Plugins tab, expand any installed plugin row to reveal the Live Log Viewer. Every time your plugin calls thecollabase:log host function (or encounters a sandbox panic, segmentation fault, or timeout), the engine instantly streams the stdout/stderr here. You can filter logs by Level (INFO, ERROR, DEBUG) to monitor background execution in production environments.
