4 ms·

With embedded platform you mean microcontroller with RTOS? Afaik there are no suitable implementations yet. It will generally be pretty hard to build something

With embedded platform you mean microcontroller with RTOS? Afaik there are no suitable implementations yet. It will generally be pretty hard to build something like this, since grpc requires HTTP/2, and that is hard to implement with no dynamic allocations and a low amount of memory. E.g. each substream requires a minimum amount of buffering, there is header decompression, etc. For pure protobuf communication on embedded systems nanopb works fine. If one doesn't need concurrent streams, HTTP/1.1 or coap plus nanopb encoded payloads work fairly well.

SlowRobotAhead 8y ago
The problem I have with nanoPB, is that the RPC comm between the app over BLE and the server over http is entirely up to me. There are no suggestions, standards, or even great examples of what the pb should contain and how it gets processed at each location. It almost becomes RESTful where I have a proto that has a request field, response field, and all the optional fields for both, when the server or app sees one of these I need all custom implementation to decide what to do with these ‘states’. It seems wrong and complex to make it all arbitrarily handled at each of three places. NanoPB is excellent. But it’s the handling of the data (calls, req/res, timeouts, errors, formats, patterns) that I wish there was something for. And yea, you got it right that with no HTTP layer it wouldn’t be gRPC on the device. But my app and server could still use that, if only the device could process the intention of the gRPC format changes / extensions.