We would like to use unleash-proxy-client-js in a service worker context, more precisely in the context of a browser extension service worker (and "non persistent background").
Background
We are facing some issues while running unleash-proxy-client-js in a service worker context (browser extension service worker).
First issue : each time the proxy is instantiated, it fetches the flags, no matter how old they are in the storage. In the context of a service worker which stops and restarts multiple times depending on its use this will cause a huge overhead on our proxy server (we have hundreds of thousands of live extensions).
Second issue : the internal use of setTimeout and setInterval which is not compatible with the lifecycle of this kind of service workers which have to use "browser alarms" instead, see documentation.
Solution suggestions
For the first issue (fetch call on load) the solution could be to check "flag expiration" on load, if flags are younger than the "refreshInterval", it should not fetch (we have to store a new "last update" timestamp) OR use the bootstrap value on first load and don't fetch (wait for next refresh).
For the second issue (usage of setInterval), we could expose as public methods the "refresh" toggles and metrics so that library consumers can call them themself if needed (we could so add our own "alarm" to refresh the toggles and metrics).
Describe the feature request
We would like to use
unleash-proxy-client-jsin a service worker context, more precisely in the context of a browser extension service worker (and "non persistent background").Background
We are facing some issues while running
unleash-proxy-client-jsin a service worker context (browser extension service worker).First issue : each time the proxy is instantiated, it fetches the flags, no matter how old they are in the storage. In the context of a service worker which stops and restarts multiple times depending on its use this will cause a huge overhead on our proxy server (we have hundreds of thousands of live extensions).
Second issue : the internal use of
setTimeoutandsetIntervalwhich is not compatible with the lifecycle of this kind of service workers which have to use "browser alarms" instead, see documentation.Solution suggestions
For the first issue (fetch call on load) the solution could be to check "flag expiration" on load, if flags are younger than the "refreshInterval", it should not fetch (we have to store a new "last update" timestamp) OR use the
bootstrapvalue on first load and don't fetch (wait for next refresh).For the second issue (usage of
setInterval), we could expose as public methods the "refresh" toggles and metrics so that library consumers can call them themself if needed (we could so add our own "alarm" to refresh the toggles and metrics).