Code generation has a trust problem: if the generator and its tests share an assumption, the tests pass and the code is still wrong. grpc-over-datachannels generates its gRPC runtimes and most of its tests from one source of truth, which makes that failure mode easy to fall into. The defence is an oracle: stock, Google-maintained gRPC implementations that never saw our generator.
The bridge
A TCP-to-DataChannel proxy connects the two worlds. On one side it speaks ordinary HTTP/2 gRPC over TCP, exactly what grpc-java and grpc-go expect. On the other it speaks the grpc-dc frame protocol over a WebRTC DataChannel. A generated client can therefore call a stock server, and a stock client can call a generated server, with every frame crossing both wire formats on the way.
What gets graded
The interop matrix runs the standard gRPC test vocabulary — unary, server-streaming, client-streaming, bidirectional streaming, empty calls, large messages, status codes, metadata, and deadlines — across generated clients and servers in JavaScript, Go, Rust, Python, and the other generated languages, against the reference implementations as the source of truth. The same generated scenario table (the BDD suite) also runs natively per language and inside real Chromium, Firefox, and WebKit browsers via Playwright, so a behaviour has to be right in three independent venues before it counts.
Why this matters more than unit tests
Unit tests verify our code against our understanding. The oracle verifies our understanding against the ecosystem's. Every divergence the proxy runs surfaced — in framing, trailers, timeout formats, or stream teardown — was a place the specification in our heads differed from the one on the wire, found before a user could find it for us. If you generate protocol code, budget for an oracle: it is the only test suite that cannot agree with your mistakes.
No comments:
Post a Comment