Hey folks, I would like to share my ideas with you and get your opinion.
Currently I setup a microservice on a low-power device, comparable with a Raspberry Pi. This device operates a docker environment and there is no communication done to any network outside the device. There are roughly: - 5 containers offering services - 20 containers consuming all of these services - all containers are written in different languages, that gRPC supports I already set up a proof of concept with one server and one client and am impressed how easy it was and how fast I could have results. These are the requirements: - connections to the servers are long living (days and weeks) - on connection loss, the clients have to reconnect very soon (keep-alive) - most of the services are request-response pattern with streaming - some of the services require broadcasting from the server to all clients - protobuf has to be used for backward-compatibility - the message size is rather small (few kByte if at all) For the broadcasting I implemented a pub-sub pattern inside the server, where every client registers to a topic and gets a notification (via stream) if the topic changes. What I am interested in is whether gRPC is the correct protocol for what I am going to achieve. The alternative is MQTT with protobuf. I did some short performance-test and was surprised, that MQTT with QOS2 and protobuf was even slower than gRPC (client to broker and back, vs. unary grpc call to server). *Do you have any thoughts on that?* The problem with MQTT is, that the logic of filling the protobufs has to be implemented and maintained in each language again and again. "Drawbacks" that I see with gRPC (compared with MQTT): - every server needs its own .proto definition for the services (a common for the messages may be used) - every client has to be connected to all 5 servers and maintain the connection (keep-alive, etc.) simultaneously - (I think it is not possible to connect one client to different servers providing different RPCs - so you need to instantiate multiple clients inside the application) - broadcasting requires implementation on top of gRPC - gRPC handles (to my understanding) RPCs of different clients in threads. Handing over data between threads requires proper mutexing and hence is more error prone and in some circumstances slower when waiting for mutexes. *Happy to read any of your thoughts.* BTW: Can someone explain the difference between server-side and client-side keep-alives? Is it possible to enforce client keep-alives at the server? -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/a29766e0-13df-4c1a-b421-9767900c089a%40googlegroups.com.
