write directly from interface to DB

These are my opinions, there are pros and cons:
Pros:
1. Certainly, it will reduce the load on process execution engines - since no process instances will be needed to launch just for writing to the database. And you do not need to create a process model for it.
2. The function is asynchronous - so it wont block the SAIL UI when its writing to the DB.
3. Can be used on all kinds of SAIL UI and Web APIs.

Cons:
1. If it fails - it will fail silently- this is both a good thing and a bad thing - in case of the "old way", you at-least get an alert. In this case, the alert will be in the logs only, it wont be available in the Appian designer. This can cause hard to detect issues, and fixing them.
2. Agree with stefanh791 - that more than often we want more processing to be done on the data before we write to DB. That's a good point - although one could argue that we can create an expression rule which will encapsulate all the processing logic before writing to the DB.
3. I am more worried about the case of "side effect". This function causes side effect in the sense that it updates/writes the data - it modifies something in the system. This is desirable in some cases: eg: you want to edit the record data from the summary dashboard directly, instead of creating a related action to do it.
But, consider a scenario - let's say you have a tempo report. Somewhere in the interface for the tempo report, you have used the a!writeTodataStoreEntity() function. Now, its possible that this function is writing to the database, and the tempo report is using the same database table as its source. This can be confusing. Imagine a scenario - you click on the slice of a piechart(which shows percentages), the data gets updated asynchronously in the background. You click once again on the slice of report - the data is fetched again.
This time it will show different data! The user may wonder how did the percentages of the slices change immediately. Yes, this is a contrived example - but it is totally possible.
4. You need to make sure that you refresh the interface with updated data - if you are using this function, the database will be updated asynchronously. The interface may then need to show the updated data - of course the function provides "onSuccess" and "onError". But, I have not found it straightforward to refresh the data on the interface as soon as the function updated the database.

These are my opinions, there are pros and cons:
Pros:
1. Certainly, it will reduce the load on process execution engines - since no process instances will be needed to launch just for writing to the database. And you do not need to create a process model for it.
2. The function is asynchronous - so it wont block the SAIL UI when its writing to the DB.
3. Can be used on all kinds of SAIL UI and Web APIs.

Cons:
1. If it fails - it will fail silently- this is both a good thing and a bad thing - in case of the "old way", you at-least get an alert. In this case, the alert will be in the logs only, it wont be available in the Appian designer. This can cause hard to detect issues, and fixing them.
2. Agree with stefanh791 - that more than often we want more processing to be done on the data before we write to DB. That's a good point - although one could argue that we can create an expression rule which will encapsulate all the processing logic before writing to the DB.
3. I am more worried about the case of "side effect". This function causes side effect in the sense that it updates/writes the data - it modifies something in the system. This is desirable in some cases: eg: you want to edit the record data from the summary dashboard directly, instead of creating a related action to do it.
But, consider a scenario - let's say you have a tempo report. Somewhere in the interface for the tempo report, you have used the a!writeTodataStoreEntity() function. Now, its possible that this function is writing to the database, and the tempo report is using the same database table as its source. This can be confusing. Imagine a scenario - you click on the slice of a piechart(which shows percentages), the data gets updated asynchronously in the background. You click once again on the slice of report - the data is fetched again.
This time it will show different data! The user may wonder how did the percentages of the slices change immediately. Yes, this is a contrived example - but it is totally possible.
4. You need to make sure that you refresh the interface with updated data - if you are using this function, the database will be updated asynchronously. The interface may then need to show the updated data - of course the function provides "onSuccess" and "onError". But, I have not found it straightforward to refresh the data on the interface as soon as the function updated the database.