Asynchronous Data Refresh in OutSystems

SHARE ON
Share on facebook
Share on twitter
Share on linkedin

I wanted to start by sharing the average attention span study.

Asynchoronous Data refresh in Outsystems

It has been a continuous challenge to every engineer to squeeze every little bit of logic to give information immediately. Engineers are coming up with different designs that don’t rely on a clock but rather fires up signals that indicate completion. This applies to both hardware and software which is where “asynchronous communication” comes in.

Asynchronous communication is transmission of data, generally without the use of an external clock signal, where data can be transmitted intermittently rather than in a steady stream. — Wikipedia

Modern browser supports this placing some limitations to protect from connection choke.

Asynchoronous Data refresh in Outsystems

https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser

OutSystems takes advantage of this browser feature in Reactive and Mobile framework by having the Data source and Aggregates triggered in parallel when loading a page.

Asynchoronous Data refresh in Outsystems
Asynchoronous Data refresh in Outsystems

However, there will be times where we need to refresh them again and by using the usual way, we are only able to refresh synchronously.

Asynchoronous Data refresh in Outsystems
Asynchoronous Data refresh in Outsystems

Notice the wait before DataAction2 gets to be triggered which means waiting time is compounded to 600~ msThis is fine if DataAction2 is dependent on the result of DataAction1. I find it sometimes that this is not the case and therefore could be improved by taking advantage of the browsers multiple connections.

The strategy is to wrap them to another client action.

Asynchoronous Data refresh in Outsystems
Asynchoronous Data refresh in Outsystems

And call the wrappers on JavaScript.

Asynchoronous Data refresh in Outsystems
Asynchoronous Data refresh in Outsystems

This ended up refreshing them at the same time and both requests ended in 300~ ms compared to 600~ ms using the usual way.

In applying this strategy, please make sure that the code dependencies have been reviewed and dev team is aware why such code exists because maintaining it is another story 🙂

 

John Salamat
Technical Lead
Connect with John on LinkedIn

PhoenixDX Icon

Subscribe to receive updates

Sign up for the latest articles from the Tech Community, PhoenixDX and OutSystems.
PhoenixDX Icon

Subscribe to receive updates

Sign up for the latest articles from the Tech Community, PhoenixDX and OutSystems.