James, you made me happy by sharing experience and mentioning inter-service communication :D I'm just glad to see other people having similar problems that I've had in the past.
It is funny that you gave a code example in the very beginning which does not work in a microservice world. Let me prove you wrong! (in a good sense) I've been building new microservice programming concepts where you can choose a communication mechanism without writing any code!
Hey Serge, thanks for the comment. It's interesting your view that the example (albeit a very trivial example) doesn't work in a microservice world. Could you elaborate why?
DaSync looks an interesting project. I started working with Dapr last night which seems a very similar piece of work.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
James, you made me happy by sharing experience and mentioning inter-service communication :D I'm just glad to see other people having similar problems that I've had in the past.
It is funny that you gave a code example in the very beginning which does not work in a microservice world. Let me prove you wrong! (in a good sense) I've been building new microservice programming concepts where you can choose a communication mechanism without writing any code!
I wonder if this microservice project can also help with your needs.
Hey Serge, thanks for the comment. It's interesting your view that the example (albeit a very trivial example) doesn't work in a microservice world. Could you elaborate why?
DaSync looks an interesting project. I started working with Dapr last night which seems a very similar piece of work.
Of course! Let's say
IProductService
is HTTP or gRPC client. The code would work. However, now you need to handle errors if aValidateProducts
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.
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.