The plugins service is a shared service that all instances communicate with to search and download plugins into the system.
Plugins can be published independently to this service without having to deploy a new version of the lowcode system.
There are three types of plugin payloads:
Code - payloads which are predeveloped to support some sort of advanced functionality
Service - payloads which provide pre-built service definitions - such as pre-defined integrations, data services, website services etc
The service type includes the following subtypes:
integration
API
messaging
data
website
ruleset
Each plugin includes the payload along with a description (schema) of configuration that must be provided for the plugin to function correctly. The configuration for a plugin is optional.
The system must let the user configure the plugin using a form driven from the schema definition.
For example, if the system allows an integration to be created which connects to a third party API, and that third party API requires an authentication token in order to function, the configuration schema will include a single field that requests that the user provides the authentication token.
A plugin may have more than one payload within it - so a plugin may come with 1 code payload and 2 service payloads. This allows for plugins to ship all resources that are required for the plugin to function.
Plugin payloads are namespaced when they are installed - as plugin names are unique - this means that plugins should not collide with each other.
The plugins service is a shared service that all instances communicate with to search and download plugins into the system.
Plugins can be published independently to this service without having to deploy a new version of the lowcode system.
There are three types of plugin payloads:
The service type includes the following subtypes:
Each plugin includes the payload along with a description (schema) of configuration that must be provided for the plugin to function correctly. The configuration for a plugin is optional.
The system must let the user configure the plugin using a form driven from the schema definition.
For example, if the system allows an integration to be created which connects to a third party API, and that third party API requires an authentication token in order to function, the configuration schema will include a single field that requests that the user provides the authentication token.
A plugin may have more than one payload within it - so a plugin may come with 1 code payload and 2 service payloads. This allows for plugins to ship all resources that are required for the plugin to function.
Plugin payloads are namespaced when they are installed - as plugin names are unique - this means that plugins should not collide with each other.