33
Views
4
Comments
Solved
Aggregates vs data actions
Application Type
Reactive

Hi,

In terms of perfomance what's better in Reactive web, 2 screens aggregates in wich one of them is set to Only on Demand and it's refresh in the OnAfterFetch from the other aggregate or a data action?

Thank you! 

Solution

Hi @Pedro Pinela ,

for starters, I would like to point out, that you don't have to set the second one to Only On Demand, and then call it in the OnAfterFetch of the first to make sure it happens afterwards.  I'm assuming the reason you do this is that the second aggregate has result from the first as input (maybe filter or something)  

If you are sure you will always want to run second, then just put them both on AtStart, and Outsystems will detect and take care of this direct dependency between both of them.

If you are very often not running the second (dependent on details coming back from the first), use your approach with the onAfterFetch, where you can build a condition client side around refresh of the second.

I think 2 consecutive round trips to the server might be slightly slower than 1 big trip in a DataAction retrieving both, but that difference would typically much less important for performance than the queries themselves and the amount of data coming back from them.

An advantage of doing 2 screen aggregates instead of stuffing them in the same DataAction, is that the data coming back from the first aggregate will be visible to the user faster.

Dorine

Thank you for the answer. So this best practice that appears in the best practices of mobile apps is not applicable to reactive web?


well,

that's what you have to weigh and take into consideration the actual performance, how heavy those queries are, how much data is coming back, ...  

Weigh the performance cost of going twice against not showing any of your data to the user until all is retrieved.  I think maybe in mobile, this is maybe a slightly different weighing because of 4G (or maybe 3G) against WIFI, but I don't know what the difference would be between those in actual numbers.

For me, a clear example would be to retrieve both client details by id (fast), and also a list of the last 5 transactions in a big database with transactions (a bit slower), I would want to show the user details immediately, and then the list can come a few seconds later, that's fine.

Dorine

Solution

Hello @Pedro Pinela,

It depends on factors such as data volume, user experience, and control:

Two Aggregates with "Only on Demand":

Pros: Reactive nature, simplicity.

Cons: Extra fetch requests, potential delay.

Data Action:

Pros: Control, caching, flexibility.

Cons: Complexity, need to manage initial load.

Based on your requirement you can consider following things and use accordingly:

Data volume: Large data may impact performance, requiring caching and query optimization.
User experience: Decide between slight delay (aggregates) or more control (data actions).
Caching: Implement caching for performance improvement.
Testing: Perform real-world performance tests to identify the best approach.

The choice depends on specific requirements and trade-offs, and combining both approaches can be beneficial in achieving the desired performance.

Hope it helps!
Thanks

Solution

Hi @Pedro Pinela ,

for starters, I would like to point out, that you don't have to set the second one to Only On Demand, and then call it in the OnAfterFetch of the first to make sure it happens afterwards.  I'm assuming the reason you do this is that the second aggregate has result from the first as input (maybe filter or something)  

If you are sure you will always want to run second, then just put them both on AtStart, and Outsystems will detect and take care of this direct dependency between both of them.

If you are very often not running the second (dependent on details coming back from the first), use your approach with the onAfterFetch, where you can build a condition client side around refresh of the second.

I think 2 consecutive round trips to the server might be slightly slower than 1 big trip in a DataAction retrieving both, but that difference would typically much less important for performance than the queries themselves and the amount of data coming back from them.

An advantage of doing 2 screen aggregates instead of stuffing them in the same DataAction, is that the data coming back from the first aggregate will be visible to the user faster.

Dorine

Thank you for the answer. So this best practice that appears in the best practices of mobile apps is not applicable to reactive web?


well,

that's what you have to weigh and take into consideration the actual performance, how heavy those queries are, how much data is coming back, ...  

Weigh the performance cost of going twice against not showing any of your data to the user until all is retrieved.  I think maybe in mobile, this is maybe a slightly different weighing because of 4G (or maybe 3G) against WIFI, but I don't know what the difference would be between those in actual numbers.

For me, a clear example would be to retrieve both client details by id (fast), and also a list of the last 5 transactions in a big database with transactions (a bit slower), I would want to show the user details immediately, and then the list can come a few seconds later, that's fine.

Dorine

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