Hello David,

You can use the browser's local storage or session storage for small amounts of data at least by using javascript. It works on key-value basis and supports simple data types (and with strigifying and parsing also small JSONs).

For frequently fetched data you could use caching to reduce the amount of server calls. 

Hope you find these helpful or at least worth a thought. :)

BR,

Jenni

Hi Jenni,

Thanks for your reply and indeed that seems a good workaround. Also caching would decrease the amount of server calls, but it will not improve an offline way of working.

To keep things "low code" it would be better to have statics saved in the local storage by default (or optionally) from OutSystems' side. Rather than having to create this workaround. Also the case for mobile development.

For now, would you recommend to put Statics in Local storage that way? Seems quite some work.

Anyways thanks for your thoughts!

KR,

David

I think this needs to be broken down in two different issues.

Querying a static entity server side only happens if you use it in an aggregate or server action, and those run already server side, so caching the static entities locally has no benefit here.

Using static entity in client actions, blocks and screens is already executed in the browser locally, the static entities, do exists in local storage and the generated ReactJS uses it in client side operations.

So what are the specific situation where you see unnecessary calls to the server to access static entities?

I'm trying to take a look at this, euhm, what server calls could be avoided / reduced.  So far, there's 2 clear types I can think of involving static entities.

1) joined as a referenced entity into an aggregate on some other entity (e.g. in list of orders, order_status static entity is added as source) : don't see much reason to reduce / avoid this, you are already going to the server, doing a join with a static won't make it that much slower

2) widget with options to choose from : both in edit screens (i.e. in order detail, a dropdown on order_status to select status of this order) and in filters (i.e. in orders list, check boxes to indicate what statusses should be shown).  Gonna have a think on this one.

can you indicate in what other cases you feel there is too much back and forth to the server ?

I must say though, it is very likely that any workarounds we could come up with would add loads of complexity for very little advantages

For the static entities problem specifically I created this idea.

But I also feel like Local Storage could easily be ported over to Reactive Web Apps given that a Mobile App can already interact with the browser storage when running on a browser. It seems like only Service Studio is gatekeeping this option.

Of course we can use custom javascript to do it, but we have additional developer effort.