Question on OrderService requesting for resources from CustomerService

[WeiTangLau]

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]

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

[BenNeighbour]

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]

@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]

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]

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]

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