Which Message Queue Systems Are Supported by DBX for Administrative Operations?

DBX supports Apache Pulsar and Apache Kafka for administrative operations, with Pulsar offering comprehensive management capabilities while Kafka provides limited topic-focused functionality through a Java-based agent.

The open-source DBX project (t8y2/dbx) provides a unified administrative console for managing message queue infrastructure. Understanding which message queue systems are supported by DBX for administrative operations helps developers configure connections appropriately and understand capability limitations across different backends.

Supported Message Queue Systems

DBX defines supported systems through the MqSystemKind enum in crates/dbx-core/src/mq/types.rs. The runtime selects the appropriate adapter based on the connection's system_kind field, while the MqCapabilities struct determines which UI actions remain available for each system.

Apache Pulsar (Full-Featured Support)

Apache Pulsar receives comprehensive administrative support in DBX. The adapter implementation in crates/dbx-core/src/mq/adapters/pulsar.rs provides full-featured admin API coverage including tenants, namespaces, topics, subscriptions, rate limits, and token management.

Pulsar connections utilize standard REST API calls with automatic version detection and capability detection. The UI enables all administrative panes when connected to a Pulsar cluster, allowing complete infrastructure management through the desktop interface.

Apache Kafka (Limited Support via Java Agent)

Apache Kafka support operates differently through a specialized Java Kafka-Agent using JSON-RPC communication. The adapter located in crates/dbx-core/src/mq/adapters/kafka.rs exposes only topic-related features, omitting tenants, namespaces, and many admin-only functions available in Pulsar.

When managing Kafka connections, DBX forwards administrative requests to the Java agent rather than using native Kafka protocols directly. This architectural decision limits available operations to topic creation, deletion, and configuration while excluding higher-level organizational features.

RocketMQ (Reserved for Future Support)

Apache RocketMQ appears in the MqSystemKind enum as RocketMq but currently lacks an implemented adapter. The system is earmarked for future support within the DBX architecture, but no administrative functionality exists in the current codebase.

Runtime Adapter Selection and Capabilities

DBX determines which adapter to invoke at runtime by inspecting the connection's system_kind property stored in crates/dbx-core/src/models/connection.rs. The core service in crates/dbx-core/src/mq/service.rs instantiates the appropriate adapter and computes MqCapabilities to inform the frontend which actions to enable.

The Tauri backend commands in src-tauri/src/commands/mq_cmd.rs forward UI actions such as mq_list_tenants or mq_create_topic to corresponding core functions. When a user attempts unsupported operations—such as listing tenants on a Kafka connection—the system returns explicit errors and the UI disables relevant interface elements based on capability flags.

Practical Connection Examples

Connecting to Pulsar

To establish a Pulsar administrative connection in Rust:

use dbx_core::mq::config::MqAdminConfig;
use dbx_core::mq::MqSystemKind;

let cfg = MqAdminConfig {
    system_kind: MqSystemKind::Pulsar,
    admin_url: "http://localhost:8080".into(),
    ..Default::default()
};

let admin = dbx_core::mq::service::mq_create_admin(&cfg).await?;

Connecting to Kafka

Kafka connections require bootstrap server configuration through the extra map:

use dbx_core::mq::config::MqAdminConfig;
use dbx_core::mq::MqSystemKind;

let mut extra = serde_json::Map::new();
extra.insert("bootstrapServers".into(),
            serde_json::Value::String("broker1:9092,broker2:9092".into()));

let cfg = MqAdminConfig {
    system_kind: MqSystemKind::Kafka,
    admin_url: "".into(),
    extra,
    ..Default::default()
};

let admin = dbx_core::mq::service::mq_create_admin(&cfg).await?;

Listing Tenants via Frontend

The TypeScript frontend invokes Rust commands that route to the appropriate adapter:

import { mqListTenants } from '@/api/mq';

mqListTenants(connectionId)
  .then(tenants => console.table(tenants))
  .catch(err => console.error('Tenants not supported:', err));

For Kafka connections, this call fails with "Kafka does not support tenants" and the UI disables the Tenants pane based on the supports_tenants flag in MqCapabilities.

Core Architecture Files

• crates/dbx-core/src/mq/types.rs — Defines MqSystemKind, MqCapabilities, and data structures exchanged with the UI.
• crates/dbx-core/src/mq/adapters/pulsar.rs — Full Pulsar admin implementation using REST API calls.
• crates/dbx-core/src/mq/adapters/kafka.rs — Kafka admin implementation via JSON-RPC to Java agent.
• src-tauri/src/commands/mq_cmd.rs — Tauri command layer mapping UI actions to core service functions.
• crates/dbx-core/src/models/connection.rs — Stores the Connection model including the mq admin config field.
• crates/dbx-core/src/mq/service.rs — Core service selecting adapters based on MqSystemKind and forwarding requests.

Summary

• DBX supports Apache Pulsar and Apache Kafka for administrative operations according to the t8y2/dbx source code.
• Pulsar provides full administrative capabilities including tenants, namespaces, and token management through its dedicated adapter.
• Kafka offers limited topic-only operations via a Java agent using JSON-RPC, excluding tenant and namespace management.
• RocketMQ is reserved in the enum but lacks implementation in the current release.
• Runtime capability detection via MqCapabilities ensures the UI only displays supported operations for each connection type.

Frequently Asked Questions

Which message queue systems does DBX support for admin operations?

DBX currently supports Apache Pulsar and Apache Kafka for administrative operations. The MqSystemKind enum in crates/dbx-core/src/mq/types.rs defines these systems, with dedicated adapter implementations handling the specific protocols for each message queue.

Why does Kafka have limited administrative features in DBX?

Kafka operations in DBX rely on a Java Kafka-Agent that communicates via JSON-RPC rather than native Kafka admin protocols. This architectural choice, implemented in crates/dbx-core/src/mq/adapters/kafka.rs, restricts operations to topic management while excluding tenant and namespace features that Pulsar supports natively.

How does DBX handle unsupported operations for different message queue systems?

DBX computes a MqCapabilities struct at runtime that advertises supported features to the frontend. When users attempt unsupported operations—such as listing tenants on Kafka—the system returns explicit errors. The UI disables corresponding interface elements based on these capability flags, preventing invalid actions.

Is RocketMQ available in DBX?

RocketMQ is not currently available despite being reserved in the MqSystemKind enum as RocketMq. The variant exists for future implementation, but no adapter ships in the current codebase, meaning no administrative operations are possible for RocketMQ connections.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}