gRPC is a bit higher up the stack than CoAP, it's an application layer protocol that defines the messages being sent between clients and servers in a language agnostic way. While most of the projects and documentation show grpc being used with TCP it's not tied to it. I actually used it in one of my projects with a unix domain socket, and It seems at least one IoT company is using grpc and CoAp together.
The benefits being:
the client and server bindings can be generated in almost any language,
can be compressed for smaller message sizes,
can also use different (de)serialization formats. I'm currently trying to find out whether or not the protobuf package is a runtime dependency for using protobuf format, if so, using a different message type should solve the problem if we want to avoid any dependencies for some clients
lastly if someone wants to use something other than gRPC, they can still refer to the .proto files to see the structure and contents of the messages, in order to match the behavior. The server won't likely be (as) resource constrained, and can have multiple listeners, and as long as the message fields match after decoding, you would only need to define how to handle them server side, not how to process them.
the .proto files should probably be stored in a separate repository, primarily because they are generally added as submodules/subtrees in client server implementations. Also I can write these, I used them recently in another project, and feel comfortable enough with the proto language.
gRPC is a bit higher up the stack than CoAP, it's an application layer protocol that defines the messages being sent between clients and servers in a language agnostic way. While most of the projects and documentation show grpc being used with TCP it's not tied to it. I actually used it in one of my projects with a unix domain socket, and It seems at least one IoT company is using grpc and CoAp together.
The benefits being:
lastly if someone wants to use something other than gRPC, they can still refer to the .proto files to see the structure and contents of the messages, in order to match the behavior. The server won't likely be (as) resource constrained, and can have multiple listeners, and as long as the message fields match after decoding, you would only need to define how to handle them server side, not how to process them.
the
.protofiles should probably be stored in a separate repository, primarily because they are generally added as submodules/subtrees in client server implementations. Also I can write these, I used them recently in another project, and feel comfortable enough with the proto language.