Tradeoffs

Canopy purpose is a full solution 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.  However with the help of examples and AI you can have the option for a future proof solution at minimal effort.

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 independance, segmented deployment, remote attestation, and transport independence 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 drift over time. Canopy's generated JavaScript layer provides distributed type safety, keeps browser tooling tied to the same 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 have multiple transport or serialization strategy without changing the application contract.

Do not choose Canopy first when

  • The API is a simple public HTTP/JSON request-response surface.
  • The service boundary is rare enough that hand-written glue is cheaper than adopting a runtime.