I just don't get the purpose of using gRPC with rabbitmq in microservices. I know that gRPC basically calls some code remotely and rabbitmq (as any other message broker) is used for sending messages among microservices. But I just don't get the purpose of using those technologies together.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (10)
I'd say there is a very good separation.
With gRPC you call somebody else and wait for the result. (There can also be streams and so on but it doesn't matter for now.) So you generate the methods and calls for the things you want to wait for, because somebody else is also waiting for a response from you. The contract is way more strict then the fire and forget to a queue.
With the queue you can put work on there where the client calling you is not waiting for. So if a user comes by to know something about his account and you want to then send an email that's nothing the user needs to wait for. So put the email job in the queue and return him the answer to his question.
Somebody else might pick up your job and execute it eventually.
I always distinguish by the question if somebody is waiting for a response or not.
That's greate reply, thanks alot
gRPC is a RPC (remote procedure call) framework. It lets two different applications send information to each other in a formal way, so that they can be written in any language. This is built on top of Google Protobuf which is a serialization framework to represent data itself. gRPC lets applications talk to each other with standardized methods over a http/2 tcp connection sending data encoded in protobufs.
What happens if one application is talking to another app but it goes offline? What if you want to send 1 message but have it duplicated to many other apps automatically? What if you don't know who exactly to send to? Imagine what you would have to build for that - and that's RabbitMQ is.
It's a message broker system that accepts and sends messages on a topic. All the apps talk to RabbitMQ instead and it'll handle queuing messages if the listening side is offline and will let you setup complex routing rules if you need them.
If I had to guess, the original architect (or team) couldn't quite reconcile how to deal with synchronous-like communication in an asynchronous system. This isn't uncommon.
In an async system (using the bus), you submit a message and the system will process it as it gets to it, which in most cases is right away. Because the message is dropped on the queue, there's no direct way to get a response if you need one. So for example, if I wanted to provision a phone number with an SMS provider, I'd issue a message (a command) and some service would pick it up and provision it, but since I might not know what that phone number is, I'm relying on the server to tell me right now so that I can display it to the user. In this scenario, the async message pattern is problematic. In a synchronous system, I would ask for the SMS number and wait for the process to finish; the server would return the phone number directly. It's simpler and good enough for most systems, but you lose some resilience and the ability to buffer system loads.
There are a few patterns to get around this in an async system such as basic pub/sub, sagas, web sockets, etc., but I think the most common one in SOA is to have a response queue that the message producer would subscribe to after submitting the original command. When the system is finished processing the message, it'll deposit a response message into the response queue and the producer will get its answer. The most popular with web client -> server is to be event-driven over web sockets. Those that have not used these patterns before will almost always scoff at it and call it too complicated, then reject it and turn around to tack on a synchronous interface which may be what happened in your case with the rpc implementation being alone side the bus.
Well, gRPC and a message queue are two different approaches of enabling communication between multiple Microservices. A message queue results in extremely loose coupling and is useful for event-driven systems while using gRPC is a little stricter. Either way they can somehow be seen as alternatives. But I can't think of a general scenario where you would neccessarily need both of them. Who does this / what was the reason for your question?
I have new project at work. Technology stack is predefined. And this two technologies are in the stack. So I'm trying to figure everything out. More I read, more confused I get. But you make things clearer. Thanks)
Well perhaps this does not respond exactly your question about gRPC, ... and leaving aside the concept of event-oriented ... in this post programmaticponderings.com/2017/05... you can see how RabbitMQ can also be used as a message-based RPC endpoint supporter. Think about another option to communicate microservices in a synchronous way, and of course, it could break some principles of decoupling between microservices, but at the end it will depend on your domain context and your solution, I suggested that article because the first question I had about synchronous IPC was about the performance, in that article you can see some results related with it, TL;DR both approaches tested (REST HTTP and RPC/ AMQP) have almost the same performance (but, none of those had a performance improvement strategies, like clustering, caching, etc...)
Dunno the architecture, but just a guess: gRPC is for clients to request changes into the system. RabbitMQ is for listening to events (changes) from others services.
depending on your architecture and business, both are used to communication medium among micro services. gRPC for instant response for particular resources and rabbitmq for event based queue pushing and listening when and which service needed.
You can use these systems to implement event oriented microservices. This is very useful in systems which must support complex process chains.