DEV Community

Discussion on: The different faces of microservice communication

Collapse
 
tyrotoxin profile image
Serge Semenov

Of course! Let's say IProductService is HTTP or gRPC client. The code would work. However, now you need to handle errors if a ValidateProducts call fails on the network level. Then at some point, you need to replace simple request-response with a message queue to create a more robust workflow. In that case, you have to refactor the code of your services to accommodate message handlers - it is not a simple method call anymore.

D-ASYNC gives you a language-integrated way to describe inter-service communication regardless is they use a synchronous or asynchronous channels. So in that particular example, you can use a message queue when calling IProductService.ValidateProducts without re-writing the method. That will ensure the statefulness of the method execution (a state of a workflow).

And yes, dapr! In the middle of the spectrum you have dapr - a K8s sidecar that facilitates communication and state management, but does not reduce the churn of non-functional code you have to write in your app. You can put D-ASYNC and dapr together - they are not mutually exclusive ;) And I think you are right, it's hard to figure if a tech can solve your problems without trying them.

Thread Thread
 
jeastham1993 profile image
James Eastham

D-ASYNC certainly seems an interesting tool! I've got a new GitHub repo I'm using to have a play around with some of the Dapr functionality (I'll probably implement the Product/Order validation from this post as a really rudimentary example.