Harper Realtime

Harper Realtime

Overview

Harper exposes live data through the same Resource model used for REST and GraphQL. Exported tables/resources can be addressed as MQTT topics and WebSocket paths, while custom resources can override the messaging handlers when the default table behavior is not enough.

Use real-time primitives when the product needs pushed state: live feeds, activity streams, collaborative views, device telemetry, or status updates. Do not replace these with client polling unless the issue explicitly asks for polling.

Resource and topic model

• A GraphQL type marked @table @export creates a default exported table resource.
• An exported JavaScript Resource class from resources.js creates a resource endpoint with the class name as the path/topic root.
• Resource paths map naturally to subscription targets: collection-level subscriptions use the resource name, and record-level subscriptions append the record id or path segment.
• MQTT supports multi-level topics and wildcards. Use resource/# for a resource subtree and resource/+/status for one path segment.
• WebSocket subscriptions target the REST resource URL. For example, ws://localhost:9926/Activity/123 subscribes to the Activity resource record with id 123.

Keep the URL/topic names stable. If a UI depends on Activity/123, changing the resource export name is an API break.

Resource methods

The MQTT plugin routes broker messages through Resource methods:

For table-backed resources, prefer default behavior until the product needs a custom message shape, authorization check, fan-out, or derived event. When overriding, preserve built-in table behavior with super.subscribe(...) or super.publish(...) where that behavior is still wanted.

export class Activity extends tables.Activity {
  static async publish(target, message, context) {
    const payload = await message;
    await super.publish(target, payload, context);
    return { ...payload, acceptedAt: Date.now() };
  }
}

For WebSocket-only behavior, implement connect(incomingMessages) and return an async iterable. Use the default super.connect() stream when you only need to push extra server messages or clean up on disconnect.

Transport choices

Authentication is usually required for MQTT. When mqtt.requireAuthentication is false, authorization still applies at the resource/table level, so public connections must be explicitly allowed by roles or resource logic.

config.yaml wiring

Component-level config.yaml enables the app surface:

rest: true
graphqlSchema:
  files: schema.graphql
jsResource:
  files: resources.js

The root Harper harper-config.yaml, not the component config.yaml, owns broker ports and MQTT authentication:

mqtt:
  network:
    port: 1883
    securePort: 8883
  webSocket: true
  requireAuthentication: true

Keep the rest, graphqlSchema, and jsResource declarations together when a project has a custom component config.yaml. Harper does not merge custom component config with defaults. See [[harper-config-yaml]].

Filtering and message shape

• Prefer record-level subscriptions (Resource/<id>) when the UI watches one entity; use collection or wildcard subscriptions only when the product needs a feed.
• Keep published messages typed and small. Send the changed record or a compact event envelope, not a full page payload.
• Include stable identifiers in custom events: resource name, id, operation, and timestamp are usually enough.
• Treat inaccessible or unauthenticated subscribe attempts as authorization failures, not empty streams.
• Do not disable the audit log for tables that need real-time messages or replication; Harper uses it for live subscriptions.

Fabric and replication

For clustered/Fabric deployments, real-time behavior must match the deploy target:

• Verify against the same environment that users connect to, not only a local single-node process.
• Use replicated=true when deploying a component that needs to run across Fabric nodes. See [[harper-build-and-deploy]].
• Keep event handlers idempotent. A subscriber may reconnect and replay from the latest known state.
• If a bug appears only across nodes, capture the target URL, topic/path, node count when known, and the exact publish/subscribe commands in the evidence.

Local verification

1. Build generated Harper assets from source:

   bun run build
   

2. Start the component:

   harper dev harper-app
   

3. In another shell, subscribe to a topic or WebSocket path:

   npx mqtt sub -h localhost -p 1883 -u HDB_ADMIN -P "$HARPER_PASSWORD" -t 'Activity/#' -v
   

   npx wscat -c ws://localhost:9926/Activity/123
   

4. Publish or mutate the watched record:

   npx mqtt pub -h localhost -p 1883 -u HDB_ADMIN -P "$HARPER_PASSWORD" -t 'Activity/123' -m '{"status":"live"}'
   

5. Confirm the subscriber receives the expected message shape and that a normal REST/GraphQL read returns the same resulting state.

Record the command, topic/path, payload, and observed message in PR evidence. If a local Harper binary or credentials are unavailable, report that blocker instead of claiming the subscription was verified.

Project conventions

• Write resource code in TypeScript under src/; harper-app/resources.js is a generated artifact. See [[harper-resources]].
• If real-time work changes config.yaml, update the project Fabric runbook and re-run the smoke path. See [[harper-config-yaml]].
• Prefer a pushed update over a polling workaround when the issue asks for live behavior.
• For Lisa plugin edits, change plugins/src/harper-fabric, run bun run build:plugins, and commit both source and generated plugin copies.

Sources

• Resources overview
• Resource API
• WebSockets
• MQTT configuration
• Transaction logging