Components

Components are the primary unit of executable and reusable logic in RevoEngine. A component has metadata, ordered elements or files, versions, activation state, access rules, and optional deployment state.

Start with the job to be done

Do not begin by choosing a runtime. Begin by deciding what must be true when the work ends.

Validate and return

A bounded request handler: validate customer input, read or write data, and return an HTTP result.

Transform and persist

A reusable unit that imports a file, normalizes records, and returns a durable Storage or Table reference.

Share a rule

A library element that exposes calculation or policy logic through lib.LibraryName.ElementKey.member.

The Components workspace is list-first: its grid shows name, category, description, activation, type, metadata, actor timestamps, and version. Selecting a row opens a side panel with the definition. The panel exposes component identity and metadata first, then the ordered Elements editor; Studio opens the full authoring environment.

Component types

Type	Best for	Runtime
`CODE_JS`	Standard application and integration logic	Isolated JavaScript
`CODE_TS`	TypeScript-authored application logic	Transpiled, then isolated JavaScript
`CODE_JS_LIB`	Shared JavaScript business libraries	Exposed through `lib.LibraryName.ElementKey.member`
`CODE_TS_LIB`	Shared typed business libraries	Exposed through `lib.LibraryName.ElementKey.member`
`JSON_VALIDATOR`	Reusable JSON input validation	Validation pipeline
`CUSTOM_NODEJS`	Trusted code that needs npm packages or Node.js semantics	Managed custom runtime

Start with CODE_JS or CODE_TS. Choose CUSTOM_NODEJS only when Node.js packages, multi-file source, or Node-specific APIs materially simplify the solution.

Execution model

Low-code elements run in ascending order. Each element can return a value, and a later element can read it with inject(elementKey). Runtime inputs, platform calls, storage, utilities, and active libraries are available through injected globals.

const customer = await api.getDatabaseData('customers', {
  filter: { field: 'customerId', op: 'eq', value: api.input('customerId') },
  take: 1,
});

return customer.data[0] ?? null;

Lifecycle

Create or edit the component.
Validate source and configuration.
Debug transient changes in the Sandbox.
Save a new version.
Activate the intended version or runtime revision.
Observe executions through logs, traces, job history, or endpoint statistics.

For custom Node.js, saving source and making it executable are separate states. The deployment must become ready before it can be activated; a failed deployment does not silently execute unverified source. For an exact deployment binding, select a Component content digest from revision history. The digest identifies executable content across instances even when local version numbers differ; leaving the digest unset follows the latest active revision. Element metadata is editable, while reserved revision fields are managed by RevoEngine. For field-level metadata, element-key rules, type-specific configuration, and version behavior, see Component configuration.

A useful first Component

For an order-confirmation API, keep the public handler small: load a record, apply the business rule, and enqueue durable work. The background provider call belongs in a Job Component, where retry and concurrency are explicit.

const { orderId } = api.input().body;
const order = (await api.getDatabaseData('orders', {
  filter: { field: 'orderId', op: 'eq', value: orderId },
  take: 1,
})).data[0];

if (!order) api.throw(404, { message: 'Order not found' });
if (order.status !== 'READY') api.throw(409, { message: 'Order cannot be confirmed' });

return { orderId, accepted: true };

That Component can later be reused by an Endpoint, a Job template, an Event target, or an Agent tool without copying the state-transition rule.

Composition

Call another active component with api.executeComponent().
Move shared business logic into a library component.
Expose a component through an Endpoint for synchronous HTTP.
Attach it to a job template for background execution.
Publish selected components as governed Agent plugins.

Components as Agent capabilities

A Component becomes especially valuable when the same business rule must serve people, APIs, automation, and Agents. Publish the reviewed Component through an Agent plugin instead of asking a model to reproduce the logic in a prompt. This gives the Agent a narrow capability with:

a stable input and output contract;
the same versioned business rule used elsewhere in the application;
platform authorization and approval classification;
observable executions and errors;
independent testing and rollout.

For example, a pricing Component can power an Endpoint, a scheduled recalculation Job, and an Agent action without creating three implementations of the pricing rule. The Agent decides when the capability is relevant; the Component remains the deterministic execution boundary. See Tools, skills, and loading for the difference between executable tools, workflow guidance, and packages.

Do not place API keys or passwords in source or component metadata. Store them in Secrets and resolve them only when needed at runtime.

Library components always include a permanent, initially empty @default public entry point. Named exports there use lib.LibraryName.member; other elements use lib.LibraryName.ElementKey.member. See Libraries for examples and privacy rules.

Build applications

Low-code runtime

Low-code reference

Start with the job to be done

Validate and return

Transform and persist

Share a rule

Component types

Execution model

Lifecycle

A useful first Component

Composition

Components as Agent capabilities

​Start with the job to be done

Validate and return

Transform and persist

Share a rule

​Component types

​Execution model

​Lifecycle

​A useful first Component

​Composition

​Components as Agent capabilities

Start with the job to be done

Component types

Execution model

Lifecycle

A useful first Component

Composition

Components as Agent capabilities