Server action vs Aggregate refresh in client events

It is well known that calling server actions in screen event handlers should be avoided: 

"Server calls should be avoided on client events (On Initialize, On Ready, On Render, On After Fetch). These events are serialized in the request and server calls may tremendously impact the wait time to render the screen."

Both server actions as well as Aggregate/Data action refreshes are executed asynchrously in the background when called from client actions. However, the calling client action will wait until the background operation is finished and continues after that. This means that multiple refreshes and server actions are executed consecutively, waiting for the previous ones to be finished. So the total lead time of the client action can be quite long.

That is not an issue for normal client actions, but it is for sceen event handlers. Since they are serialized, the rendering can take a lot of time, so we should avoid that.

But now comes the question:

AI Mentor Studio warns for calling server actions, but not for refreshes. But the situation is the same. Suppose we have the following On After Fetch action.

Why is the left flow with the refreshes okay and the right flow not? The left end node is reached only after both refreshes are finished, which can take a lot of time. 

But why does OutSystems not warn for the situation of the left flow with the refreshes? What do I miss here?

Background information:


What kind of warning does it show? This code in an OnAfterFetch seems right. Only if you had 2 server actions it would give a warning.

This warning:

I think it is a new code pattern that is checked by AI Mentor Studio (For On After Fetch). It existed already for the other events.
And the warning is valid. Do we all agree about that?

I haven't work with AI Mentor yet. But this is new... not even Service Studio warns of server calls in "OnAfterFetch".

One way (which I truly hate) to hide the warning is to create a new Client Action which calls the server action and replace it in the code. But, again, this is just to hide the warning, not truly a solution.

AI Studio is smarter than that :-). If you encapsulate the server action call in a new client action, it discovers that.

But this post is not about fixing the technical debt, but the question why a server call is seen as a problem and an aggregate refresh is not. Both have the same impact.

I thought Mentor AI would not find that :D

Meanwhile see from other perspective: what choice would you have to refresh the sources?

Now that you bring this topic, it would be handful to have a possibility in Reactive to have create one server action to do these refreshes...

A real solution for this is to replace each of the server action and aggregate refreshes by a JavaScript:

setTimeout(function () {
}, 0);

This starts a separate asynchronous parallel thread on the client that runs the action RefreshAggr which contains the actual refresh or server action.

The screen event handler immediately continues and exits. I use this trick also in OnInitialize.

You can also use it to let all aggregate refreshes run in parallel in an OnParametersChanged for instance.

But the question remains: why does AI Mentor Studio not complain about refreshes?

Not sure why, but I know the actual behaviour allows you to have screen aggregates and data actions that are actually used to provide values to be used inside client actions, not only as data providers for screen widgets.

Saw this behaviour being used multiple times (usually with the Fetch property set to Only On Demand).

So, any change to the default behaviour of a refresh that turns its operation asynchronous is breaking change. Don't know how big would be the impact on existing applications, but for sure would break some.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.