search

eventuate-tram / eventuate-tram-sagas-examples-customers-and-orders

Spring Boot/JPA microservices that use an orchestration-based saga to maintain data consistency
Other
520 stars 236 forks source link

Question on OrderService requesting for resources from CustomerService #44

Open WeiTangLau opened 3 years ago

WeiTangLau commented 3 years ago

I not sure whether you will see this, but if you do please do have a look at my problem.

Assuming that in Order database, we store customerId to reference to the specific customer. However, if the HTTP/POST request to OrderService contains only customerName, how should we get the customerId from CustomerService?

All I can think of is sending a HTTP/GET to Customer Service for the resource. Is it possible to send an event and waits for a response from CustomerService?

BenNeighbour commented 3 years ago

Doesn't that value get passed down during the saga though?

BenNeighbour commented 3 years ago

Like you save the initial record, set it equal to itself and JPA would have generated a Primary Key for it. Maybe you should create a GetCustomerCommand? Maybe create a Java Thread lock in that class and then unlock that thread when a response is recieved. Seems a bit hacky though.....

WeiTangLau commented 3 years ago

@BenNeighbour Yes that's exactly the problem that I am facing.

My workaround is to enforce "structural integrity" at front end level. e.g. web app will fetch all customers (w/ customerId and customerName). The user will select the customer name and the relevant customerId will be passed to the Order API. The downside is that I am still not sure how to query other microservices during a saga should this is absolutely necessary.

The other way (though not preferred) is to use blocking HTTP / gRPC to fetch the data like what you have mentioned. Though kinda defeats the purpose of async saga.

BenNeighbour commented 3 years ago

Yeah to be honest I actually use gRPC for this. The only problems with that are stuff like object reflection from the stuff created via protobufs. U can define the query as either another step in the saga or call it as a gRPC service. Id recommend gRPC for the frontend as well with gRPC web.

WeiTangLau commented 3 years ago

Seems like that cant be avoided.

What about in the case of failure of gRPC communication? We can only retry right? Similar to HTTP

BenNeighbour commented 3 years ago

Yeah but gRPC offers better features for type and is substantially faster than JSON REST. Its gonna dominate the microservices industry in the near future I think. In using that for all of my Frontend to Backend calls and because it's asynchronous it works really well. There is an option in the rpc itself to use either streaming or request/response