Shared engine architecture

One Bloomberg data runtime for Python and Node.js.

xbbg is organized around public package surfaces that share one high-performance Rust/Arrow core, not around repository folders or language-specific rewrites.

Public surfaces

• xbbg for Python / PyPI
• @xbbg/core for Node.js / npm
• Rust session and worker pool
• Bloomberg C++ SDK integration
• Arrow-native output

Internal Rust crates, binding crates, native platform npm packages, and private packages are implementation details. Users choose one of the public packages; the runtime underneath stays the same.

Shared request path

1. 01Python or Node request

   Call sites use familiar helpers such as bdp, bdh, bds, async variants, subscriptions, or fixed-income helpers.

2. 02Typed request model

   Dates, securities, fields, overrides, auth, retry policy, middleware metadata, and output shape are normalized before execution.

3. 03Rust session + workers

   The engine owns reusable sessions, worker pools, event handling, retries, diagnostics, and request middleware execution.

4. 04Bloomberg C++ SDK integration

   Terminal, B-PIPE/SAPI, ZFP, TLS, SOCKS5, failover hosts, SDK logging, and entitlement paths stay explicit.

5. 05Arrow-native output

   Results flow into pandas, Polars, PyArrow, DuckDB, Narwhals, JavaScript objects, or Arrow tables without maintaining parallel wrappers.

Runtime responsibilities

Session management

Startup, service opening, auth, recovery, and failure reporting happen in the runtime instead of each application.

Concurrency

Async helpers, subscriptions, and reusable worker pools share a non-blocking Rust execution model.

Middleware

One request chain can attach request IDs, audit metadata, tracing spans, metrics, authorization checks, or policy enforcement.

Output conversion

Arrow is the canonical handoff; backend conversion happens once at the edge of the public API.

Configuration is explicit

Connection settings are system-level facts. xbbg keeps local Terminal, B-PIPE, SAPI auth, TLS, ZFP, SOCKS5, retry, and failover settings in configuration rather than hiding them in individual request helpers.

That makes production assumptions visible to reviewers, operators, and application owners.