JEN PERSON: All right.
Here we go.
This is the one.
I feel it.
MAYANK JAIN: Go for it.
JEN PERSON: All right.
Here we go.
[MUSIC PLAYING]
JEN PERSON: Hey, all you Firebase developers.
Welcome to another episode of #AskFirebase, the show
where we answer your burning Firebase questions.
And today, I am joined by Mayank Jain.
MAYANK JAIN: I'm the product manager for Firebase Remote
Config.
And my mission is to make Firebase Remote Config
an awesome platform for developers, all the app
developers.
JEN PERSON: If it's all right with you,
I'm going to start with sort of a slow pitch.
I think you'll know this really well.
Our first question is, assuming that we have multiple Firebase
projects from multiple apps using the same software,
is it possible to modify or adjust
the remote config settings of all the Firebase
projects simultaneously?
MAYANK JAIN: So, this is a good question,
and we've heard this question a lot previously.
So what we've done is instead of just solving this use case,
we solved the problem in general.
So Remote Config now has a REST API--
JEN PERSON: That's right.
MAYANK JAIN: --which you can use to manage
Remote Config from server side.
So in this question, there are multiple Firebase projects,
and they have multiple apps, and the developer
wants to adjust Remote Config settings in almost all
of them, in any combination possible.
JEN PERSON: Right.
MAYANK JAIN: That's a great use case for the Remote Config
Management REST API.
So the developer could essentially
write a Python script or Node.js.
It's a REST API, so you could wrap it up
in any language you choose.
And then build any Custom Logic.
OK, for example, imagine this.
A taxi company wants to update some parameters
in real time in their driver side app,
also on their buyer side app.
And these are two different projects.
They could potentially do it with the same REST API.
JEN PERSON: Yeah, I saw this question,
and I was really excited about it
because it gave us a chance to talk about the new REST API.
MAYANK JAIN: Absolutely.
JEN PERSON: And I will link to that below as well,
so you can check out the documentation.
MAYANK JAIN: For sure.
JEN PERSON: And we can scroll past this part,
because this is more of the same question.
MAYANK JAIN: Let me actually talk about it,
because it's actually a good problem for REST API to solve.
JEN PERSON: Yeah.
MAYANK JAIN: So the question is that there is one developer who
wants to migrate keys, a lot of keys, from one Firebase project
to another Firebase project.
Previously this was not possible.
Imagine you have 500 keys in one Remote Config project.
Are you expected to manually create
every key in the other project?
JEN PERSON: That makes my eye twitch.
That would be miserable.
MAYANK JAIN: That's impossible, right?
So, this is another great use case for the Firebase Remote
Config Management REST API where you essentially
write a script which reads information from one project
and writes the information to the target project.
And this is also a great way to set up
your different environments, which could be development
staging production.
So a production environment is where you only write,
and then [INAUDIBLE] and development environments
is where you could use a script to keep them in the same sync.
JEN PERSON: Yeah, yeah, that's another great use for the REST
API.
So, it sounds very much like these were common problems,
and you and your team were listening
and found a good solution for this.
MAYANK JAIN: Absolutely.
I mean, we can not address every problem,
so instead we saw one common theme,
which was the REST API programmatic access to Remote
Config.
So, yeah.
JEN PERSON: Remember, if you see features
that are very important, you can always file a feature request.
And we do appreciate that feedback.
You can incorporate it where appropriate.
MAYANK JAIN: Absolutely, in fact, almost all
of the features that we are building now
for Remote Config have been almost exclusively requested
by project developers.
So, well, there you go.
JEN PERSON: So we need you.
MAYANK JAIN: Yep.
JEN PERSON: OK.
What else have we got?
So, certainly, different apps have different needs
about how frequently they're going
to want to fetch new information from Remote Config.
What is the minimum speed at which
you can refresh the cache?
MAYANK JAIN: Certainly.
We've got this question so many times now from developers
that we've actually went ahead and documented this
in our official documentation.
Right now, the way Remote Config is designed,
you can fetch five times in a 60 minute window
before getting throttled from the client side itself.
Now, the important point to note is that we cannot change this
behavior right now, because it is baked into the SDK itself.
So if you start making refreshes faster than that,
you will start seeing exceptions,
throttling exceptions from the SDK.
JEN PERSON: That being said, it seems
like if you need to refresh your information more
than five times in an hour, again,
we might be looking at rather than a real config situation,
some sort of database solution might be better.
MAYANK JAIN: Absolutely.
We don't recommend hitting the limits,
not because we can not support it on server side,
but because doing such fast refreshes in your app
basically kills the need for the fundamental reason we
have the cache in there for.
So we don't advise people doing such fast refreshes,
until and unless there's a very specific use
case that calls for it.
So if you think you, as Jen said,
you need more, faster refresh rate,
you should definitely explore [INAUDIBLE] or Firestore.
JEN PERSON: You know, one of my favorite cases
I have seen of using Remote Config is--
I don't know if you've seen that talk that some Firebasers gave
about Santa Tracker, and how Santa Tracker, which
is an app that is made here at Google
by some people on the Firebase team,
they use Remote Config to sort of be
able to turn games on and off.
So if they were finding that something was particularly
buggy, they were able to remove that from the UI,
and make it a better user experience.
MAYANK JAIN: Absolutely.
I would like to add on to the discussion we just had.
One thing to note is that the cache explanation
strategy is set on the client.
So if-- say, for example, if both me and Jen received
the data, the cache, at different times,
our caches might expire at different time intervals
as compared-- you know, like, it's not, like, 12:00,
midnight, all caches expire.
Right?
If I receive my first Remote Config
fetch one hour earlier than how she received it,
and we both have the same fetch timing,
my cache will expire one hour before.
So--
JEN PERSON: That's a good point.
MAYANK JAIN: Yeah, don't think of it like it's clock based.
It's just that it's based on a number of hours,
or a number of the cache expiration
that you set in the SDK itself.
JEN PERSON: Cool.
Good to know.
Thanks so much for coming on the show
and talking about Remote Config.
It's one of our great grow features.
And I thank all of you for watching.
And remember, if you have questions about Remote Config
or any other sort of Firebase feature,
hit them up with the hashtag #AskFirebase on social media.
And who knows?
You might see your question here on a future episode.
And be sure to subscribe to the Firebase channel,
so you can check out all the other great content
that we make on our YouTube channel.
Thanks for watching, and we'll see you in a future episode.
MAYANK JAIN: Bye.
JEN PERSON: Bye.
No.
Good god.
What?
Don't.
I don't want any more questions.
I'm done.