Firebase Remote Config Throttle

[Charles Aylward]

Hi FB Team,

I am trying to utilize Remote Config to provide my application with a localized string. I have a Remote Config parameter with language conditions.

config_hello_string:

    default: "hello"

    danish: "hej"

    german: "hallo"

    english: "hello"

    ....

I need an updated string to be Fetched from Remote Config whenever the language on the phone is changed. The Remote Config throttle is preventing more than "a few fetches per hour". That means if the user changes the language on their phone more than "a few" times in an hour, they will hit the throttle and no longer receive a localized string. This creates a bad user experience for my app (yes, it's not realistic that the language will change that frequently, but edge cases should be accounted for).

What solutions are there for this problem?

Best,

Charles

[Mayank Jain]

Hi Charles,

The current Remote Config SDK allows 5 fetches in a 60 minute window (before being throttled)

Could you tell us more about the use case where the users might want to switch the device locale more frequently than that?

Thanks

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/a48d7952-e135-4b7d-9340-9533709e97b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mayank Jain

Product Manager, Firebase Remote Config

+1 (650) 447-9489

[Charles Aylward]

It would be great if a fetch with a change in the device conditions, even if just language, wouldn't count towards the throttling...

I'm developing an app for 80+ locale variations and would like to use Remote Config but the limitation on the number of changes per hour is deal-breaking..

Thanks for the quick response.

Charles

[Mayank Jain]

Hi Charles,

Thanks for that information.

I am still curious to know - what is the use case where the user will need to switch device language every 5 minutes?

Maybe then I could suggest an alternate solution.

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/80767663-4f0c-47f4-b803-301c78f4443b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Samuel Stern]

Hi Charles,

In addition to Mayank's question, I'd like to add that if you just need to overcome this limit in development you can enable developer mode in Remote Config to retrieve configuration variables more often than then production limit:

https://firebase.google.com/docs/remote-config/android#how_it_works

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADefqxQFcdn0RQN5JQdxmp-_-ha2XwbAg5U_Jy%3DerJ71TwRgAg%40mail.gmail.com.

[Charles Aylward]

My use case may involve a demonstrating an app to an international audience showcasing the localization features. Also, while it may seem a trivial concern, competitors or third party reviewers may test this functionality in our app and notice it as a flaw in our system leading to negative reviews or worse. Unfortunately, we are forced to take these things into consideration.

Taking a step back, I would think a change in the Conditions for a Remote Config parameter would be an acceptable scenario to not count against the throttle. I understand the throttling is there to prevent overloading the Remote Config server with redundant fetching, but if the fetch request provides a different value based on the device conditions, the 5 fetches per hour seems like a pretty severe limitation. I've looked through the documentation, but is there a more technical explanation for the throttling behavior?

Best,

Charles

[Andreas B]

Charles,

I wonder if other ways would be more appropriate for your situation:

1. Does the string that needs to be localized really change that often that it needs to be configured separately from an app release? If not, using standard localization features of Android would be much simpler.

2. If this is not possible, you could load all localized strings at once (either via Remote Config, or other Firebase products like Realtime Database, or any other way for that matter) and then select the correct one based on the device locale's getLanguage().

3. Last but not least, having a good enough fallback value for those cases where Remote Config cannot be updated (not just because of throttling, but simply because of offline devices, areas without wifi and/or cell coverage, ...) seems to be a necessity, anyway.

[Mayank Jain]

Another idea to try...

Send all localized values as a json object in a remote config key. Keys in this object are locale names (like en_IN) and values are localized strings in that locale.

So when fetch happens, you get all locales in one go, instead of just 1. Now when locale switch happens, you just reference the json object and pull out the locale based key.

Will that work?

If not, then as Andreas suggested, try doing this with Realtime DB.

Let us know your thoughts.

Cheers!

--

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/6fcc503d-66ec-4ca6-bf9e-5eca22247459%40googlegroups.com.

[Charles Aylward]

Thanks for the suggestions. The main drive to use Remote Config was to take advantage of the localization server-side to avoid needing to pull a locale string from the phone and match that with a key on the app-side. With the Realtime Database or a json string we'd face the same obstacle. 

Best,

Charles

[Mayank Jain]

I will keep this use case as a suggestion for future planning.

Thank you for bringing this up.

Cheers!

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/ff3eeac0-7935-470b-9b5c-129190916036%40googlegroups.com.