Hacker News Reader

Comment by cedricd | Hacker News Reader

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?

View on HN

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.

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.

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.

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 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.

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.

Hehe - that's cool. Thanks for the explanation.

Reply on news.ycombinator.com