5 ms·
So if I understand correctly, I can define bits of JSON / values in your interface. Then when my client app loads it'll hit your service backend to fetch them.
by cedricd 6y ago
So if I understand correctly, I can define bits of JSON / values in your interface. Then when my client app loads it'll hit your service backend to fetch them.
Seems pretty interesting. In terms of how it works it seems similar to how LaunchDarkly fetches its feature flags.
In practice if we configured all small bits of data in here it'll happen at app startup and be on the critical path. Do you have some sense about the latency there?
- jeremyis 6y agoHi. 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 agoSpeaking 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 agoThanks 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 agoI 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.