4 ms·

Hi. Today, our clients fetch values on-demand (so, not necssarily on app startup - it's when you call configly.get(key)). The values are then cached on the clie

Hi. Today, our clients fetch values on-demand (so, not necssarily on app startup - it's when you call configly.get(key)). The values are then cached on the clients according to a TTL you can set yourself. Latency was around ~200ms (I believe ~40ms is on the server). Do you feel it's important to push this number down? I think LaunchDarkly might do some background fetching. We were slightly concerned about additional bandwidth / battery usage on mobile for this pattern and aren't quite ready for a push pattern.

kall 6y ago
Speaking for me, a 200 ms delay would be too much when values are fetched on demand. And I assume it‘s higher outside the US? Imagining a mobile app, adding a 200ms delay to a screen transition that would otherwise not fetch data would not be ok. If it fetches other data, it may be fine. I would rather have the relevant values fetched in the background before they are read. Because of the latency sensitivity I would probably try to hack this together on cloudflare workers+KV if I needed it. I would expect <100ms latency in most cases on that. I think this is a general worthwhile service, especially the focus on CMS/copy over feature flag tools, but low latency would be something I would look for in a feature list.
- jeremyis 6y ago
  Thanks for the great feedback. That's something we can definitely give more priority to. I actually had an iOS library version that would poll infrequently in a background thread and had a synchronous API. Something like: Configly.init(API_KEY, { values: [keyOne, keyTwo]}) // (other code runs) print(configly.shared().get('keyOne')) // would be cached by the background thread but was slightly concerned about unwanted bandwidth/battery usage for mobile users but perhaps that mode would be useful exactly for the situation you describe.
  - kall 6y ago
    I think if battery/data even becomes a concern, you have already put too much data into config and probably need a database? Does anyone really care about a couple hundred KB (at most) these days? Or am I underestimating the config size/usage?
- jeremyis 6y ago
  (I don't see an option to reply to your other comment -- I'm guessing it's too deeply nested, so replying here) >I think if battery/data even becomes a concern, you have already put too much data into config and probably need a database? > Does anyone really care about a couple hundred KB (at most) these days? Or am I underestimating the config size/usage? I could be wrong but I think this is a concern some mobile developers have. It came from user feedback but we should definitely look into it more.
  - mst 6y ago
    Re replying, more likely the issue was the comment was too new, HN doesn't let you insta-reply as a means to make it harder to get into a minimal-thinking flamewar style argument.
    - jeremyis 6y ago
      Hehe - that's cool. Thanks for the explanation.

kall 6y ago

Speaking for me, a 200 ms delay would be too much when values are fetched on demand. And I assume it‘s higher outside the US? Imagining a mobile app, adding a 200ms delay to a screen transition that would otherwise not fetch data would not be ok. If it fetches other data, it may be fine. I would rather have the relevant values fetched in the background before they are read. Because of the latency sensitivity I would probably try to hack this together on cloudflare workers+KV if I needed it. I would expect <100ms latency in most cases on that. I think this is a general worthwhile service, especially the focus on CMS/copy over feature flag tools, but low latency would be something I would look for in a feature list.

jeremyis 6y ago
Thanks for the great feedback. That's something we can definitely give more priority to. I actually had an iOS library version that would poll infrequently in a background thread and had a synchronous API. Something like: Configly.init(API_KEY, { values: [keyOne, keyTwo]}) // (other code runs) print(configly.shared().get('keyOne')) // would be cached by the background thread but was slightly concerned about unwanted bandwidth/battery usage for mobile users but perhaps that mode would be useful exactly for the situation you describe.
- kall 6y ago
  I think if battery/data even becomes a concern, you have already put too much data into config and probably need a database? Does anyone really care about a couple hundred KB (at most) these days? Or am I underestimating the config size/usage?
jeremyis 6y ago
(I don't see an option to reply to your other comment -- I'm guessing it's too deeply nested, so replying here) >I think if battery/data even becomes a concern, you have already put too much data into config and probably need a database? > Does anyone really care about a couple hundred KB (at most) these days? Or am I underestimating the config size/usage? I could be wrong but I think this is a concern some mobile developers have. It came from user feedback but we should definitely look into it more.
- mst 6y ago
  Re replying, more likely the issue was the comment was too new, HN doesn't let you insta-reply as a means to make it harder to get into a minimal-thinking flamewar style argument.
  - jeremyis 6y ago
    Hehe - that's cool. Thanks for the explanation.