CODEWITHSUNDEEP
webcachingarchitectureclient-servercqrs
Lamar
Lamar

Reputation: 641

Client Server Data Exchange Persistence - Smells

Suppose I have a client that sends some RunLogicCommand with input to a server. The server responds with some output which is a report for the user to verify. At this point, the server has not persisted anything. The client then sends back the entire report in a separate SaveCommand which will then persist the report data.

To me, certain parts of this exchange seem unnecessary. That is, once the user has verified the report, it seems unnecessary for them to send the entire report back to the server for persistence. Perhaps there is a chance some sensitive data could exposed here as well?

What is the typical approach in this case?

I can see two options:

  1. The user just sends the RunLogicCommand with Input AGAIN with some flag specifying it should be persisted. I don't really like this option since the logic could be complex and take some time to compute.
  2. cache the report on the server (or different service or even db), then just have the client send back the SaveCommand with the ID of the report to save.

Are there any problems with either of these approaches? Is there a better, more typical approach?

Thanks!

Upvotes: 0

Views: 38

Answers (1)

Shiraz Bhaiji
Shiraz Bhaiji

Reputation: 65431

There is no single best solution here:

The cons for the approach you mentioned firsts are:

  • Increased network traffic,potentially increasing costs and giving slower response times
  • Can you be sure that the document you sent is the same one that has been received. You can but it would require extra work.
  • As you mentioned, there is an increased risk that sensitive data is exposed. However, you are sending it to the client.

The cons for the first of your two options are:

  • Running the report twice would increase the load on the server, giving an extra cost due to the need for more processing capacity.
  • If the underlying data has changed between the two requests. Then the report that was verified by the user and the report stored in the database may not be the same.

I would use a variation of your second option:

  • Store the report in the database as soon as it has been generated, with status "waiting for user verification"
  • When the user verifies the report, update the status as verified.
  • To avoid having many unverified reports in the database, you could have a batch job that checks for and deletes all unverified reports that are older than x days.

Upvotes: 1

Related Questions