RPC proxy — Quick guide

The RPC proxy is the single endpoint that fuses the whole stack behind one URL. Front-ends send every JSON-RPC call to the same address; the proxy looks at the method name and forwards each call to the right backend — the node for consensus, nexus-go for social data, the wallet indexer for wallet history — and returns the result. From the browser it is one origin; the fusion happens server-side.

One call, one backend

The proxy does not merge responses or fan out. Each request matches exactly one route and goes to exactly one backend. That keeps it simple and predictable: the "single endpoint" is a router, not an aggregator.

Where it sits

                         ┌─────────────► blurtd          (consensus, broadcast)
  front-ends ──► RPC proxy ├─────────────► nexus-go        (bridge.* + social reads)
   (one URL)              └─────────────► wallet-indexer  (wallet_history.*)

It is a generalized JSON-RPC reverse proxy (Python / Sanic, HTTP and WebSocket), config-driven and originally built for general blockchain RPC use, deployed here as Blurt's public RPC entry point.

How routing works

A small JSON config declares named targets (the backends) and an ordered list of routes — a regex on the JSON-RPC method mapped to a target, with an optional response-cache TTL. The first route whose regex matches the method wins.

{
  "targets": { "blurtd": "…", "nexus": "…", "wallet_indexer": "…" },
  "routes": {
    "^bridge.(.*)":            { "target": "nexus",          "cache": 5 },
    "^wallet_history.(.*)":    { "target": "wallet_indexer"             },
    "^condenser_api.broadcast_(.*)$": { "target": "blurtd"              },
    "^condenser_api.(.*)$":    { "target": "blurtd"                     }
  }
}

So bridge.get_ranked_posts goes to nexus-go, wallet_history.get_status to the wallet indexer, and everything consensus to the node — all through one URL.

What it gives the stack

• One origin for the browser — no per-service CORS, no multiple URLs.
• Method-level routing — social, wallet-history, and consensus calls each reach the service built for them.
• Response caching — hot read methods are cached (per-route TTL, in Redis) to shield the backends.
• HTTP and WebSocket — same routing for both transports.

Run it

pip3 install -e .
rpc_proxy --config ./config.json

It needs a reachable Redis for caching, and it listens on a configurable host/port (default loopback), fronted by your web server for TLS. See the Reference for the config model and the full Blurt routing map.

Next

• Reference — the config model, route matching, caching, request forms, and the complete Blurt routing table.
• Source: Saboin/temp-rpc-proxy.