How Pandora.js Exposes Application Info via Endpoints and IPC

In the previous article we introduced the Metrics system of Pandora.js, which generates numeric metric data; however, many scenarios also require informational (string) data.

Metric data represents numeric values, distinguished from informational data.

In Pandora.js, informational data is defined as application information, divided into static (e.g., app name, start path, configuration, module version) and dynamic (e.g., process list, interface parameters) categories. These also include the Metrics data described earlier.

Pandora.js uses an EndPoint mechanism to expose this information via RESTful interfaces for users or external schedulers.

Built‑in information interfaces include:

Health check information

Process information

Daemon information

Node.js runtime information

Current Metrics results

Link monitoring information

Recent error log information

…etc.

How It Works

All interfaces are documented; the following diagram illustrates the data structure distribution.

Pandora.js separates the information channel into a monitor side and other process sides. The monitor runs outside business processes and communicates with them via IPC to maintain stability and isolation.

The framework provides a basic IPC service for simple data transmission; details are omitted here.

Basic Data Format

Although Pandora.js does not enforce a specific output format beyond Metrics, using a consistent format improves readability and extensibility. JSON is the natural choice for JavaScript information structures.

{
  "appName": "hello-world",
  "baseDir": "/home/admin/hello-world",
  "nodeVesion": "v8.3.9",
  "nodePath": "/home/admin/hello-world/node_modules/"
}

To represent multiple dimensions (e.g., app and node), the structure can be extended:

{
  "app": {
    "appName": "hello-world",
    "baseDir": "/home/admin/hello-world"
  },
  "node": {
    "nodeVesion": "v8.3.9",
    "nodePath": "/home/admin/hello-world/node_modules/"
  }
}

This yields two dimensions— app and node —facilitating later display and filtering.

To format the exposed parameters, Pandora.js uses a builder object:

function invoke(args, builder) {
  builder.withDetail("app", {})
         .withDetail("node", {});
  return builder.getDetails();
}

The invoke function is the core data‑collection entry point for clients.

Data Transmission

Following Spring‑Boot naming conventions, Pandora.js calls the client side an Indicator and the server side an EndPoint, establishing a many‑to‑one relationship.

Indicators broadcast their initialization data; the receiving EndPoint registers them under its group field, ensuring correct association.

class HealthEndPoint {
  private group = 'health';
  registerIndicator(data) {
    if (this.group !== data.group) {
      // ignore mismatched group
      return;
    }
    // further processing …
  }
}

Grouping, endpoint aggregation, and remote calls constitute the three core keywords of Pandora.js’s data‑exposure ecosystem.

Reverse Channel

Simple remote invocation may not meet performance or real‑time requirements for large‑scale data such as link traces or error logs. Two solutions exist: client‑side caching (which risks consistency) or server‑side caching with proactive reporting. Pandora.js adopts the latter, called the “reverse channel”.

The reverse channel adds a report() method to actively push data to the server, enabling efficient handling of high‑volume, cross‑process information.

class DuplexIndicator extends Indicator {
  transferType = 'duplex';
  messengerClient;
  report(data) {
    this.messengerClient.report(this.getClientUplinkKey(), data);
  }
}

class DuplexEndPoint extends EndPoint {
  protected registerIndicator(data, reply, client) {
    if (this.group !== data.group) {
      return; // ignore mismatched group
    }
    // registration logic …
  }
  abstract processReporter(data, reply?) {
    // implement in subclass to handle reported data
  }
}

By invoking the client’s report method at appropriate times, the server processes incoming data via the overridden processReporter, for example writing it to a cache. The source code for error collection demonstrates this workflow.

Not the End

Metrics remain a special case of information transmission, using IPC with distinct handling; details will be covered in the next article, which will also discuss external interface design.