Skip to main content

What you’ll accomplish

You will understand the WebSocket data path, create a small Node.js relay, emit valid RuntimeDataEnvelope v1 snapshots, test locally, and prepare a production wss:// endpoint.

Who must provide the WebSocket server?

Layarva Player is a WebSocket client. It connects to an endpoint and listens; it does not create the server that publishes your data. For the current Secure WebSocket mode, the customer or integration partner normally provides the relay. You can:
  • host a small relay on your own server or container platform;
  • use a managed service that supports WebSocket broadcasting; or
  • connect directly to an existing provider only when its endpoint already satisfies the Layarva message and security requirements.
Layarva does not currently provide a generic hosted WebSocket broker for customer Widget data.
If updates every few seconds are sufficient, use Structured Widget Push API. Push API is simpler to operate because no continuously connected server is required.

How it works

The Player rejects malformed messages, messages larger than 1 MiB, and messages whose sourceId does not exactly match the Widget ID. When the connection closes, it reconnects with exponential backoff up to five minutes.

Prerequisites

  • Node.js 20 or later for this example.
  • A host that supports long-lived WebSocket connections.
  • A DNS name and valid TLS certificate for production.
  • The Unique Widget ID and workspace ID.
  • Data that can be transformed into the selected Widget’s semantic schema.

Create the relay

Create a new server project outside browser code:
Create server.mjs:
This example broadcasts a complete schedule snapshot every 30 seconds and immediately after a Player connects. Replace buildWidgetData() with a database query, event subscription, or provider call.

Run locally

macOS or Linux:
Windows PowerShell:
Connect a test client:
Use this ws://localhost address only for local testing. Do not publish a Design with a localhost endpoint; a remote Player would interpret localhost as the Player device itself.

Understand RuntimeDataEnvelope v1

Use this ordering:
The Player accepts the envelope directly or inside { "envelope": { ... } }.

Deploy with TLS

Production Studio configuration accepts wss://. Deploy the Node process behind a TLS-terminating load balancer or reverse proxy that supports WebSocket upgrades. Example reverse-proxy requirements:
Confirm that:
  • the TLS certificate is valid for the hostname;
  • the endpoint is reachable from every Player network;
  • idle connections are not closed too aggressively by the proxy;
  • the service restarts automatically after a crash or host restart;
  • the relay can handle one connection per online Player using that Widget source.

Configure Studio

  1. Select the Widget in Studio.
  2. Open Properties → Data Source.
  3. Select Secure WebSocket.
  4. Enter wss://stream.example.com/widgets/<WIDGET_ID>.
  5. Set Reconnect to five seconds initially.
  6. Keep valid Static JSON as a fallback.
  7. Save and publish the Design.

Security model and current limitation

TLS protects data in transit, but wss:// alone does not decide which client may subscribe. The current Studio WebSocket configuration does not provide arbitrary authentication headers, cookies, or a configurable subprotocol. Therefore:
  • never put API keys, passwords, or long-lived bearer tokens in the URL;
  • keep provider credentials inside the relay, not in Studio or the Player;
  • expose only display-safe data;
  • use network allowlisting, private connectivity, or a gateway appropriate to your deployment when access must be restricted;
  • do not use the current direct WebSocket mode for sensitive data on an unauthenticated public endpoint.
If the upstream provider requires a secret, the relay authenticates to that provider server-side and publishes a separate display-safe WebSocket endpoint to Players.

Reconnect and Last Known Good

  1. The Player connects using the configured initial reconnect delay.
  2. A valid message becomes the current snapshot and is persisted as Last Known Good.
  3. A malformed message is rejected without replacing the valid snapshot.
  4. On close, retries back off exponentially up to 300 seconds.
  5. After expiresAt, data is treated as stale.
  6. After staleAt or the Player’s maximum stale policy, the snapshot is no longer eligible.
  7. Static JSON remains the final safe fallback.

Production validation

  • wss:// is used with a valid certificate.
  • The endpoint is reachable from the actual Player network.
  • A snapshot is sent immediately after connection.
  • Every message is less than 1 MiB.
  • sourceId exactly matches the Widget ID.
  • sequence increases and contentHash is recomputed from data.
  • Timestamps are parseable and ordered correctly.
  • data passes the selected Widget schema after declarative mapping.
  • Relay restart and Player reconnect have been tested.
  • Last Known Good and Static JSON fallback have been observed during an outage.
  • Capacity testing accounts for every connected Player.

Troubleshooting