Skip to main content

Ecosystem Overview

beachcomber has client SDKs for seven languages plus a POSIX shell polyfill. All SDKs are stdlib-only (no external dependencies) and are published to their native package registries.

Install

SDKRegistryInstall
Rustcrates.iocargo add beachcomber-client
PythonPyPIpip install libbeachcomber
Node.jsnpmnpm install libbeachcomber
GoGo modulego get github.com/NavistAu/beachcomber/sdks/go
LuaLuaRocksluarocks install libbeachcomber
RubyRubyGemsgem install libbeachcomber
CGitHub ReleaseSource tarball, .deb, .rpm, or AUR
Shell / POSIXSee the Polyfill

The Rust SDK ships as beachcomber-client on crates.io; the other language SDKs are libbeachcomber on their native registries.

When to use an SDK vs the CLI

Shelling out to comb g. is fine for one-off queries from shell scripts, prompts, and status bars. For anything that queries more than a handful of keys per second, or needs to stream updates, use a language SDK:

  • Persistent connections — open a Unix socket once, reuse it for every query (avoids per-call socket setup).
  • Connection context — set a working directory once with set_context; subsequent path-scoped get calls don't need to repeat the path.
  • Typed results — scalar/object dispatch in idiomatic types for each language.
  • Lower latency — skip exec/fork overhead; SDK get is ~15 µs vs ~34 µs for the CLI.

Feature matrix

All SDKs cover the common read path. store and watch are protocol-level operations that are not yet exposed in any language SDK — use the raw protocol over a Unix socket to drive them, or call comb w / comb p on the CLI.

SDKgetpokecontext / sessionliststatusstorewatch
Rust
Python
Node.js
Go
Lua
Ruby
C

Need a language that isn't listed? The protocol is newline-delimited JSON over a Unix socket — any language that can open a socket can be a client in a few dozen lines.