Using FauxRPC to debug transcoding HTTP/JSON to gRPC
A Stack overflow question involving transcoding HTTP/JSON to gRPC, piqued my interest. I had a hunch on the solution but was initially dissuaded from attempting a repro because of the complexity:
- recreate proto
- implement stubs
- deploy gRPC-Gateway
I then realized that FauxRPC would probably address much of the complexity and it did.
I created foo.proto
:
syntax = "proto3";
import "google/api/annotations.proto";
import "google/api/field_behavior.proto";
import "protoc-gen-openapiv2/options/annotations.proto";
// Was not defined in the question.
service Foo {
rpc FetchResource(GetResourceRequest) returns (ResourceResponse) {
option (google.api.http) = {get: "/v1/resource/{resource_id}/group"};
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_operation) = {
summary: "Get Resource from group"
description: "Retrieve resource info"
};
}
};
// Should be named FetchResourceRequest to match the RPC method name.
message GetResourceRequest {
string resource_id = 1 [
(google.api.field_behavior) = REQUIRED,
(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "Resource UUID v4."
example: "\"81042622-4f02-4e85-a896-172edd5381b6\""
}
];
ResourceFilter resource_filter = 2 [
(google.api.field_behavior) = OPTIONAL,
(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
description: "\"RESOURCE_FILTER_FIRST\""
}
];
}
// Empty response for demonstration purposes.
// Was not defined in the question.
// Should be named FetchResourceResponse to match the RPC method name.
message ResourceResponse {}
enum ResourceFilter {
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_enum) = {
title: "Resource Filter"
example: "\"RESOURCE_FILTER_FIRST\""
};
RESOURCE_FILTER_UNSPECIFIED = 0;
RESOURCE_FILTER_FIRST = 1;
}
The proto depends on googleapis
(Google’s repo containing definitions for Google’s services) and grpc-gateway
(containing protoc
plugins and protobuf sources).
Bare Metal: Pico and CYW43
The “W” signifies that the board includes wireless. Interestingly, the wireless chip is an Infineon CYW43439) which is itself a microcontroller running its own ARM Cortex chip (M3). The Pico’s USB device includes another ARM microcontroller. So, with the dual Cortex (or Hazard) chips that are user programmable, and the 8 PIOs, these devices really pack a punch.
As a result of adding the wireless (microcontroller) chip to the Pico, the Pico W’s on-board LED is accessible only through the CYW43439. Yeah, weird but it makes for an interesting solution.
Bare Metal: WS2812
This one works!
Virtual WS2812s
I’d gone cough many years and never heard of 1-Wire and, suddenly, it’s everywhere.
Addressable LEDs are hugely popular in tinkerer circles. Addressable LEDs come in myriad forms (wheels, matrices) but commonly they’re sold as long strips. The part number is WS2812 and they use 1-Wire too. Each, often multi-color (RGB) LED (often known as a pixel), is combined with an IC that enables the “addressable” behavior.