我一直在考虑将gRPC用于"物联网"类型的设备；像传感器这样不太受约束的东西；更像是单板计算机内置设备，如机器人、无人机等。需要的是设备和集中控制器之间的接口，因为这些设备是单独开发的，可能由其他公司开发。因此，版本化的接口语言是必须的；它不应该仅仅出现在word文档中；可编程的东西，比如头文件、WSDL、IDL或ProtocolBuffer。此外，在设备和控制器之间，应该为常见的用例(如注册、重新注册等)指定行为。这可以在word文件或一些非技术文件中。
协议缓冲区(第3版)中的(rpc)接口规范以及通过gRPC的有效实现使我选择了它而不是CoAP/LWM2M(乐山Java和C++实现)。
在使用了LWM2M和grPC之后，我想说grPC对开发人员更友好；接口定义和实现与OMA LWM2M过程相比是快速的。当然，gRPC中没有Observer Notify，但是MQTT就足够了。
严格来说，不能将LWM2M与gRPC进行比较。LWM2M不仅仅是接口，它还定义了许多物联网案例中的行为，如BootStrap、Registration、KeepAlive、SW Upgrade等，其通用HTTP(如GET、PUT)在URL类型的可寻址资源上使其非常完整。然而，这些行为中的大多数都可以通过一些努力进行自定义定义。
我们计划策划的一些物联网设备远不是灯泡之类的头脑简单的设备，更像机器人。是否有人将gRPC用于类似目的。任何成功的失败故事分享
在gRPC for IoT中，我会错过MQTT MQ功能，如消息排队、代理桥接QoS参数。或者对于CoAP，通过SMS传输的带外消息。在这种情况下，gRPC是"；只是"；RPC框架，其假定总是通过TCP连接。
我们考虑的解决方案与Joe的解决方案相同，其中包括CoAP+Protobuf:
- Protobuf&它的IDL是一种非常有用的方法，可以以集中的方式定义和管理我们的API。谷歌的api linter以及aip都是保持一切正常的高质量资源
- CoAP用于传输：物联网设备的轻量级协议。它几乎在每个RTOS/embedded/平台上都可用，而且它适应了我们在这个世界上通常面临的低带宽。作为Thread选择的协议，以及Project Connected Home Over IP对它的支持也有所帮助
- 对消息使用Protobuf，无论它们是请求/响应，甚至是物联网设备推送的事件消息。nanopb已经解决了一个问题，它是一种用于嵌入式系统的兼容原导线的C代码生成器
- 基于IDL生成我们自己的存根，以在CoAP和nanopb代码上创建我们自己的包装器。通过利用CoAP可观察机制，支持一元调用，也支持服务器流
我冒险在一个连接了"设备"的项目中使用了它；这些是像树莓派这样的小型电脑。总的来说，这是一次很好的经历；使用的语言主要是C++和Java，还有Node.js中的JavaScript；负载平衡是我们没有做到的；我读到基于HTTP/2的负载平衡很棘手；将更新该部分；计划为此使用Kubernetes。具有版本化接口的整体容器技术-GRPC似乎很适合(微型)服务
我将esp32和R_Pi与CoAP和protobufs一起使用。据我所知，gRPC不支持esp32/8266。我对此很满意，但没有对lwm2m进行任何具体测试。在这里实现