ArcadeDB releases native Python and TypeScript drivers for HTTP and gRPC protocols

ArcadeDB’s new native drivers eliminate the need for manual REST API calls or borrowed third-party clients, which previously limited access to a subset of ArcadeDB’s features. The drivers are generated from ArcadeDB’s published OpenAPI and Protobuf contracts, ensuring they stay in sync with the server’s capabilities. This reduces the risk of protocol mismatches and simplifies updates when the server evolves. However, the drivers are still in early development, and compatibility is tied to specific server versions, requiring engineers to track version mappings in the READMEs.

The choice between HTTP and gRPC drivers is not arbitrary. HTTP drivers are the default recommendation for most workloads, as they work in all environments, including browsers and serverless functions, and integrate seamlessly with existing HTTP infrastructure like proxies and tracing tools. gRPC drivers, on the other hand, are designed for sustained, throughput-sensitive workloads, such as bulk inserts or large result streaming, where a single long-lived connection is advantageous. The trade-off is added complexity, as gRPC requires more dependencies and is incompatible with browser environments due to the server’s lack of gRPC-Web support.

The drivers assume a client-server deployment model, meaning they cannot be used with ArcadeDB’s embedded mode. For Python, this requires Python 3.10 or newer, while the TypeScript drivers are ESM-only and need Node 20 or later. The TypeScript drivers also enforce modern JavaScript practices by disallowing `require()` in favor of `import`. Engineers must also be mindful of timeouts: omitting a timeout in the HTTP drivers disables it entirely, which can lead to hung requests in production if not explicitly configured.

The drivers support ArcadeDB’s multi-model querying, allowing the same `query()` method to execute SQL, Cypher, or Gremlin commands without driver-level changes. This flexibility simplifies application code but requires engineers to ensure their queries are compatible with the chosen language. The result envelope structure is consistent across drivers, though the article notes that truncated results may require additional handling. For authentication, both basic and bearer tokens are supported, with the latter useful for session-based workflows after an initial login.