Why Your Front-End Client Should Populate Audit Fields

1st Reason: Consistency

We all love consistence. Throughout the ages, people have been mind-blown by the consistent patterns.
There should be consistency in populating the properties of the models as well. To be more clear, Name, Email and similar properties
are given by the client (i.e. frontend app). So should all other properties. The-Standard compliant API treats all properties the same.
As a result, this approach clears out the question of how to decide what properties can be considered as audit fields. For example,even though CreatedDate and UpdatedDate can be easily set the developer might find difficult to automatically set CreatedBy and UpdatedBy fields in the server-side.

In addition, this approach applies Single-Responsibility Principle to the different components of our enterprise application:
Client provides, server validates.

2nd Reason: Migration

Enterprise applications migrate large volumes of data from one database to another every now and then. General practice is that a
developer writes a script that migrates directly between two databases, ignoring business validations logic. In return, it might create
“bad data” which needs to be fixed manually by accessing master data. This type of issue might leave the engineers debugging the server-side
code for a couple of work-days until they figure out why the system is broken. The issue might be easier to figure out for those “senior”
engineers who have built the system, yet stressful and hard for the “junior” engineer who just got accepted the job offer.

On the other side, when you migrate data in The-Standard complient system, you create instance of your server with audit field validations
turned off. The system will retrieve data from one database and store it in another, making sure that data being migrated is in good format.

3rd Reason: The Need to Be Modified

If the developer takes care of populating audit fields, they need to shoulder the responsibility of updating the values as well.
Think about populating updated date field, this adds extra complexity to the core business logic which, in itself, can be complex in
enterprise systems

4th Reason: No Need for DTO

You might have heard of the term “DTO”, which stands for Data Transfer Object. Most engineers use this approach to hide away the magic that
backend code is performing under the hood. When your API doesn’t perform any magic, the developers are freed from mapping and similar data manipulation
tasks.