10

For a long time, when it comes to the microservice architecture, NATS and Kafka are the first options that come to my mind. But recently I found this gRPC template in dotnet core and that grasped my attention. I read a lot about it and watched a lot of videos but I don't think any of those could address gRPC correctly as they usually contrast between gRPC and message brokers or protocols such as REST which I guess is pretty inappropriate although SOAP would be relevant here. My assumption is that gRPC is a modern version of SOAP with better performance and less implementation hassle due to it protocol buffer. And I think that gRPC can by no means be compared against Kafka or NATS. And also that it cannot replace RESTful service as neither could SOAP.

Now, the question, to what extent are my assumptions true? For example, when it comes to selecting a communication bridge between nodes on a cluster, do I have to put gPRC among my options now (NATS, Kafkam Rabbit, etc) or should I consider that when creating a web proxy to bridge external request to my microservices?

Finally, how about real-time communication, can gRPC replace websocket/socket.io/signalR completely? What does it replace?

Arnold Zahrneinder
  • 4,788
  • 10
  • 40
  • 76
  • The NATS documentation contains a [comparison page](https://docs.nats.io/nats-concepts/overview/compare-nats) that provides some high-level characteristics between NATS, gRPC, Kafka, Pulsar and Rabbit. – Arnold Schrijver Jun 03 '23 at 18:12

3 Answers3

14

I often see people misplacing these technologies by one crucial aspect: public authentication.

For instance, check this graph: enter image description here

This is a benchmark of Inverted Json (https://github.com/lega911/ijson), comparing some tools, such as iJson, RabbitMQ, Nats, 0MQ, etc.

Notice that Nats, ZeroMQ and iJson are not meant to be used as public end-points (for instance, Nats have user/password, token and keys, but it is useless in an open environment, such as web browsers, because there is no way to make the key non public).

On the other hand, GRPC works just fine with JWT and Oauth2, making it completely safe to public end-points (as safer as any other HTTP endpoint), 'cos those tokens are server-signed (so, even tough they are public, they can't be forged or tempered with)

So, what I'm trying to say is: there are techs meant to face public and techs meant to glue together servers and process within servers (which are private connections).

GRPC is public, ZeroMQ and iJson are totally private (iJson, for instance, don't have any kind of authentication). Nats works with keys or passwords, so, although is "safer" than iJson and ZeroMQ, it is not meant to be public.

When you say REST (I'm assuming HTTP here, because REST is just an architecture), websocket/socket.io/signalR, you are depicting all public interfaces. GRPC will cover you here (it's comparable to REST as request/response and websocket/socket.io/signalR because it supports half and full duplex streaming (similar to sockets)).

Nats, iJson, ZeroMQ, on the other hand, are not meant to do that. They are meant to communicate between services.

So, basically, REST/websocket/socket.io/signalR = gRPC.

Internal communication between services (in the same or in different servers) = NATs, iJSON, ZeroMQ.

(notice that I'm not even considering the other technologies in the graph, because they are products, IMO, not simple libraries you can use to achieve an end, such as RabbitMQ, nginx, etc. The other ones I'm not familiar enough to be able to make an opinion (but I'm surprised by the uvloop in that graph)).

JCKödel
  • 723
  • 9
  • 19
7

Your intuition is correct that gRPC is not comparable to an asynchronous queueing system like kafka, Rabbit, etc.

It is however a replacement for synchronous server to server communication technologies often implemented over SOAP, RPC, REST, etc. where you are expecting to get a response from another server rather than firing a message into a queue and then effectively forgetting about the message.

Ken Rabe
  • 149
  • 3
0

gRPC is definitely an option for real-time communication. It can replace socket communication if you are not streaming to the browser(No gRPC support), have a look at the Bidirectional streaming support.

About replacing Kafka/Rabbit, gRPC can be used as a PubSub system as it supports Bidirectional streaming but I would not recommend it.

Alexsandro Souza
  • 806
  • 7
  • 14
  • 2
    Note that gRPC for Web is SUPPORTED! I've used it and it works well although not as versatile as other gRPC libraries (Java, Python, Node etc) https://grpc.io/docs/languages/web/basics/ https://github.com/grpc/grpc-web – Nickson Yap Sep 17 '20 at 14:38
  • gRPC is not built for Pub/Sub it is meant for RPC with no broker (different architecture) As of Sept 2020, there are is no well-maintained open source Pub/Sub brokers made using gRPC. – Nickson Yap Sep 17 '20 at 14:42
  • I meant that the browser doesn't support it. Grpc-web uses Envoy proxy the requests. It is a workaround which I strongly not recommend. You are adding a complexity that is not required. – Alexsandro Souza Sep 18 '20 at 19:31
  • Anyways, your answer is wrong because gRPC is supported on the browser and I have done gRPC streaming on the browser Of course Envoy is needed for CORS & HTTP/1.1 fallback (security & compatibility) – Nickson Yap Sep 19 '20 at 07:35
  • 2
    The browser doesn't support gRPC. Without Envoy proxying an HTTP request to gRPC it would not work. I suggest you study more about it. If you are saying that it is possible to perform gRPC fom the browser, try to remove Envoy then. As a project lead, I don't want to add Envoy to my stack. The whole complexity of grpc-web is unnecessary. You may want to check this project to learn how to effectively manage a gRPC API https://github.com/apssouza22/modern-api-management – Alexsandro Souza Sep 20 '20 at 08:43