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.
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