Dubious and dangerous communication pattern for checkout

[Alexander Allacher]

To reduce the communication that the order service needs to do on checkout, all the product data get sent to it, so it does not need to request it from the catalog service.
When using the MVC Web App the requests get send to the BFF, which makes a synchronous request to the catalog service, and then sends the data to the order service.
Arguably, this design choice is confusing at best and a security hazard at worst.

The explanation for this is twofold:
First, it provides less benefit if the BFF makes synchronous requests to the catalog service and not the order service.
It only moves the communication to a place where it is not expected.
In this case, it is especially confusing, as only the product details get requested in sync on checkout, but not the stock.
To check the stock availability, the order service needs to make an asynchronous request to the catalog service.

Second, it is a security hazard, as the requester needs to check the product data before sending it to the order service.
This is especially important when the product data gets sent from the frontend, as these requests can be manipulated.
Unfortunately, this project has fallen into this trap.
For the second frontend, the WebSPA, the data does not get checked by the BFF and gets sent directly to the services behind.
By modifying the requests sent by the WebSPA, I was able to change the price of the products and buy them for a lower price.

As the Intend of this project is to teach people how to design microservices, such dangerous constructs should be avoided.