8

I have been toying with the idea of using gRPC for 'IoT' type devices; not very constrained things like sensors; more like single board computer inbuilt devices like robots, drones and the like. What is needed a interface between device and centralized controller as the devices are developed separately and possible by other companies. So a versioned interface language is a must; and it should not be just in a word document; something programmable like a header file or WSDL or IDL or ProtocolBuffer. Also between device and controller the behavior should be specified for common use case like registration, re-registration etc.This can be in word file or in some non technical document.

The (rpc) interface specification in Protocol Buffer (ver 3) along with the efficient implementation via gRPC is leading me to choose this over CoAP/ LWM2M (Leshan Java and C++ implementation).

Having used both LWM2M and grPC, I would say that gRPC is more developer friendly; interface definition and implementation is fast,compared to OMA LWM2M process.Of course there is no Observer-Notify in gRPC, but for that MQTT should suffice.

Strictly one cannot compare LWM2M to gRPC. LWM2M is not just the interface but defines behavior in lot of IoT cases like BootStrap, Registration, KeepAlive , SW Upgrade etc and its universal HTTP like GET, PUT on an URL type addressable resource makes it very complete. However most of these behaviors can be custom defined with some effort.

Some of the IoT things which we plan to orchestrate are far from little brained devices like bulbs, and more like robots. Has anyone used gRPC for similar purposes. Any success of failure stories to share

Roberto Caboni
  • 6,078
  • 10
  • 19
  • 34
Alex Punnen
  • 3,420
  • 36
  • 52
  • asked in grpc community too; could not get a response there; so posting here;https://groups.google.com/forum/#!topic/grpc-io/H0DBwvUqIDA – Alex Punnen Jan 30 '17 at 12:14
  • 1
    Although it may look complete I have been vaguely following gRPC and it is really brand spanking new. I'm testing it out for Node.js micro services internally, but I wouldn't be confident to say it is battle tested and/or production stable. You may be safer with what you know or just plain protos. Unless you are happy to play the long game, of R&D/prototyping and/or sticking with what is likely going to be the best foundation and not having to worry about big rewrites, as gRPC becomes more stable over time. (Maybe within a year it could be considered a solid library) – Nexii Malthus Jan 31 '17 at 17:18
  • Thanks, now I know gRPC exists out there! I'm doing some research on not too constrained M2M and two things are bottlenecking me. 1st is transport is closer to hardware than it seems. Coap is standardized by Arm implemented in C so that's good. 2nd is security no one cares about because they expect to sell and bail in a year when evildoers from evil empires strip the company bare of its intellectual property. I can't figure out PKI for MQTT so can't have that sticking out there exposed to the internet on an industrial machine. Its got to be a holistic solution – Arthur Tarasov Aug 11 '20 at 02:50

4 Answers4

5

The thing I would miss in gRPC for IoT are the MQTT MQ capabilities like queueing of messages, broker bridging QoS Parameter. Or for CoAP the Out of Band messages over SMS Transport. In this context gRPC is "just" an RPC framework which assumes to be always connected over TCP.

Roberto Caboni
  • 6,078
  • 10
  • 19
  • 34
Holger Winkelmann
  • 51
  • 1
  • 3
3

I have taken the plunge and used it in a project with connected 'Devices'; These are small computers like Raspberry-pi. Overall it has been good experience; and languages used are C++ and Java mainly and also JavaScript in Node.js . We have used this as Dockerized microservices; Load Balancing is what we have not done; and I read that HTTP/2 based load balancing is tricky; Will update that part; planning to use Kubernetes for that. Overall Container technology with versioned interfaces - GRPC seems like a good fit for (micro) services

Alex Punnen
  • 3,420
  • 36
  • 52
2

We were thinking in the same solution as Joe's, which includes CoAP + Protobuf:

  • Protobuf & its IDL are a really helpful way to define and govern our APIs in a centralized way. Google's api-linter as well as AIPs are high quality resources for keeping everything sane.
  • CoAP for transport: Lightweight protocol for IoT devices. It's available in practically every RTOS/embedded/platform and it's adapted to the low bandwitdh we usually face in this world. Being the protocol chosen by Thread and the support Project Connected Home Over IP is giving to it does also help.
  • Use Protobuf for the messages no matter they are Request/Response or even event messages pushed by the IoT device. An already solved problem by nanopb which is a protobuf wire compatible C code generator for embedded systems.
  • Generate our own stubs based on the IDL to create our own wrapper over CoAP and nanopb code. Unary calls are supported and also server streaming by leveraging this to the CoAP observable mechanisms.
Gorka Lerchundi Osa
  • 402
  • 3
  • 9
0

I use an esp32 and R_Pi with CoAP and protobufs. As far as I know gRPC is not supported for esp32/8266. I'm pretty happy with it, but didn't do any concrete testing against lwm2m. Implementation is here

Joe
  • 23
  • 3