We want locally stored data to be rendered as quickly as possible. Thus we would ideally be following something like the stale-while-revalidate pattern: load local data and render it, then fetch network data, then replace the rendered data with the received network data if stale.
I believe we may having something similar to this already implemented. Because we are using full-arc nodes, all peers are an authority for all data, and thus peers never fetch from the network, even for get_links requests with GetOptions::Network, instead waiting to ingest data via gossip. This should be confirmed.
If not, we should consider implementing like a stale-while-revalidate pattern by making 2 redundant calls when loading data: the first with GetOptions::Local, the second with GetOptions::Network.
We want locally stored data to be rendered as quickly as possible. Thus we would ideally be following something like the stale-while-revalidate pattern: load local data and render it, then fetch network data, then replace the rendered data with the received network data if stale.
I believe we may having something similar to this already implemented. Because we are using full-arc nodes, all peers are an authority for all data, and thus peers never fetch from the network, even for
get_linksrequests withGetOptions::Network, instead waiting to ingest data via gossip. This should be confirmed.If not, we should consider implementing like a
stale-while-revalidatepattern by making 2 redundant calls when loading data: the first withGetOptions::Local, the second withGetOptions::Network.