Tradeoffs

Canopy is a complete RPC foundation for distributed systems.

The strongest fit is a system where generated type-safe interfaces, serialisation flexibility, transport choice, and remote object lifetimes all matter. If you only need a public JSON API, a smaller tool will usually be easier to adopt. Canopy can be evaluated incrementally by starting with one interface and one boundary.

Comparison guide

gRPC, Thrift, and conventional service RPC

Good default choices for public service APIs and broad cross-language teams. Canopy is designed for multiple serialisation formats and transports: it focuses on C++ object-like interfaces, remote references, serialisation independence, segmented deployment, optional remote attestation, and transport choice below the generated contract.

Protocol Buffers or JSON alone

Serializers define payloads but leave the proxy, stub, routing, callback, and lifetime behavior to application code. Canopy treats serialization as one replaceable layer inside a fuller RPC runtime.

Hand-written WebSocket protocols

Fast to start, but schemas, error paths, and browser/server assumptions can drift over time. Canopy's generated JavaScript layer provides distributed type safety and keeps browser tooling tied to the interface shape used by the implementation.

Choose Canopy when

  • Your system crosses process, machine, plugin, or trust boundaries repeatedly.
  • You need callbacks, streaming, or one-way event delivery as first-class interface features.
  • Remote object identity and lifetime are part of the design, not incidental implementation details.
  • You want to change or combine transport and serialization strategies without changing the application contract.

Do not choose Canopy first when

  • The API is a simple public HTTP/JSON request-response surface. And you do not have a need for future hardware attestation.
  • The service boundary is rare enough that hand-written glue is cheaper than adopting a runtime.