Hi,
when executing a data app the execution context or the loading of the app itself can take quite some time. As follows an example:
Executor stopped
Executor starting
DataApp Loading Screen
The above steps, for a fairly simple workflow, consumed about 30 seconds. Another app required substentially more time, though. Presenting a cached version would drastically reduce perceive loading time. More on the psychological aspect here but suffice to say that even a few seconds can drastically decrease the perceived quality of a service (especially in retroperspective):
I’d like to propose to introduce a caching feature of a data app. I.e. if no (re-)calculation is required and it is only about visualisation, where the rendering is done on client side via JavaScript, data apps could become quite snappy / instantaneous to load and interact with.
Goals
- Cut down on loading time
- Reduce hosting expenses
- Decrease time to app-interactivity
Based on the capture workflow nodes concept, a part of a workflow could be encapsuled so it’s already computed data becomes permamently available as teh default app state.
In the following example the already rendered app could be cached and only upon hitting “Refresh”, the KHB would start crunching data.
Form a theoretical technical approach I’ve got more ideas like providing a “base executor” with the default nodes like GroupBy, some sort of pre-heat appraoch, to cut down on executor start ups.
Offloading certain calculations or filtering to the client-side, might alos be an appraoch.
Best
Mike