Module 5 · Exercise · ~60 min · Real Go & protoc toolchain

Build a gRPC Client & Server

End-to-end: write a proto, generate Go stubs, implement a server with one unary and one server-streaming RPC, drive it from a client running on a bufconn in-memory transport. Same shape as the Module 7 capstone, with stubs you control.

Toolchain required

This exercise requires buf (install instructions) and the Go protoc plugins. The exercise's README.md walks through setup. Without them, you can read submitter.proto and server.go but can't run the tests.

The shape you're building

              examplev1.SubmitterServer  ← you implement
              ┌──────────────────────────┐
              │  Submit(req) → resp       │ ← unary
              │  StreamUpdates(req, srv)  │ ← server streaming
              └──────────────────────────┘
                          ▲
                          │ bufconn (in-memory)
                          ▼
              ┌──────────────────────────┐
              │  examplev1.SubmitterClient│ ← used by tests
              └──────────────────────────┘

Why bufconn

google.golang.org/grpc/test/bufconn is an in-memory net.Conn. It lets you start a gRPC server and dial it without binding to a TCP port. Faster than real TCP, deterministic, perfect for integration tests. Real Canton-adjacent code uses it constantly for the "test against a real client/server, just not over the network" cases.

What gets tested

Submit, happy path — non-empty command_id, party, payload → ACCEPTED.
Empty command_id rejected — server-side validation.
Idempotency — same command_id submitted twice returns the same submission_id.
Streaming receives all 5 — straightforward consumption loop.
Streaming respects cancel — short context cancels mid-stream; server stops sending.

What you walk away with

Muscle memory for the buf generate workflow.
Confidence reading generated proto Go code.
The bufconn pattern for testing.
An idempotent server, which is the shape you'll need for any production submitter.