[MUSIC PLAYING]
ANDREA WU: Hi, everyone.
I'm Andrea from the Firebase team.
And today, I'm going to show you how to get started
with Remote Config for the web.
Why would you want to use Remote Config in the first place?
Well, you can use it to change and customize
behavior and appearance of your app
without making your users retrieve an app update.
This can be really useful for feature flagging
if you have a new feature that you
want to test out with a small group of users
before rolling out widely.
And it's also useful in A/B testing
for when you have different approaches to solving a problem
and want to test them out to see which option
yields the optimal user engagement or retention
or other result.
Additionally, it's helpful if you
want to personalize your app automatically
using machine learning.
The best part of all of this is it
can be done with just a few lines of code.
So let's go ahead and see how we would do this.
There are many ways to include a library in a web app.
But in this video, we'll be using npm and webpack.
If you want more information on how to set that up
with Firebase, check out this other Firebase fundamental
video.
Let's get started.
Here, I'm in my editor and starting
from the same starter code you'll
have at the end of our setup video
linked in the description.
Following that video involves installing Firebase with npm,
which means you'll have Remote Config ready to use, as well.
So now in my entry point file, index.js,
I can initialize a Firebase app after grabbing
the configuration information from our Firebase project
in the console.
Next, we'll have to get the instance of Remote Config which
holds all of our parameter values.
Every Firebase subpackage has a getter function
that retrieves an instance of a service,
like Remote Config in this case.
As a side note, don't worry about calling this
getRemoteConfig() function too many times,
as it returns the same instance when you call it with
the Firebase app.
Now let's do something fun with Remote Config.
We're going to display a Spanish greeting message
to 10% of Spanish-speaking users,
and an English greeting otherwise.
To setup values, I'll need to create a parameter in Firebase
console, and then we'll write code to use it in the web app.
In Firebase console, we'll navigate to Remote Config.
This screen is called the Parameter Editor.
Here, I can create a parameter with a name,
select the Data type for the value of this parameter,
then setup values that will appear based on a condition.
Let's call our parameter greeting.
And since we want to show a message banner,
the Data type will be a String.
Next, we'll create a condition, which can be many things,
like your user's country or region, platform,
or device language.
It can also be a random percentile of all users.
Since we want to show a message banner
to 10% of our Spanish-speaking users,
let's create a condition named Spanish 10%.
We can then pick languages from this dropdown
and we can type in Spanish here and select it.
This will get our users who use their device in Spanish.
To get only 10% of our Spanish-speaking users,
we'll add another condition by clicking on "and,"
and we can pick User in random percentile and type in 10 here.
In this bar down here, we can see how many
users satisfy this condition.
Let's hit the Create condition button,
which then will be added to this parameter.
For all users who satisfy this condition,
we'll give them a value--
in this case, the message banner we want to show.
Let's go ahead and enter Hola, which means hello.
For each parameter, we'll also have
to show a default value, the value that this parameter will
have when the condition above here is not met.
Let's go ahead and make the default value Hello.
You might wonder what this button does here
on the right, where it says Use in-app default. If this
is selected, no value is provided
for that parameter when an app fetches the values.
All right, so now we have a parameter all
set with this conditional value.
10% of our Spanish users will see Hola,
and everyone else using our app will see Hello.
We'll Save the parameter and Publish changes,
which makes the values available for our app to consume.
Let's take a look at the app code
to see how we can use these values.
First, we'll have to pull the values from Firebase, known
as fetching, and then enable them on the device, known
as activating.
Conveniently, there is a function called
fetchAndActivate() that does both of these at once.
And it returns a promise resolving to true
if the current call activated the fetched configs or false
if the fetched configs were already activated.
If we wanted to fetch or activate only,
there are the respective functions to do that, as well.
Why would we want to fetch only or activate only
without doing the other?
Well, if we continuously fetch and activate,
users may have jarring experiences.
Let's say we changed a value on Firebase console.
Instead of Hello, we want to say Welcome instead.
And we published these changes, which
means these values are immediately
available to our users.
Now as a user of the app, imagine us being on the page
with their greeting message, and we currently see Hello.
If the greeting message parameter
was fetched and activated, that Hello will suddenly
change to Welcome, which would be very odd.
Imagine if these jarring experiences extended
beyond a greeting message.
What if some functionality changed
while the user was using it?
Probably not a great user experience.
Fetching at some given interval is normally fine
because it won't actually change any of the values in the app.
But activating the values needs to be done thoughtfully.
A good time to activate fetched values
is the next time a user opens the app because the user will
have the same experience while in the app this time.
After we fetch and activate the values,
we'll want to use those values in the app code
to serve to users.
To get a particular parameter, we'll
use the parameter name as a key to get the parameter value
from the RemoteConfig object.
Whatever value gets stored in the greeting variable
is the value served to a user for the greeting parameter.
And just as a reminder, since we set
it to be Hello or Hola in the console,
users will be served one of those values
based on whether they satisfy the condition of being
a Spanish speaker in our randomized 10% user group.
We'll use this variable in our HTML element
that displays this greeting.
Related to fetching and activating,
fetch calls are throttled and return an exception
if an app fetches too many times in a short time period.
The default minimum fetch interval is 12 hours,
meaning configs won't be fetched more than once
in a 12-hour window, regardless of how many fetch calls are
made in your code.
You can configure this to a higher number,
resulting in more time between fetches,
by setting settings.minimum FetchIntervalMillis
in your app.
And you'll want to make sure it doesn't fetch too frequently.
Otherwise, the calls will get throttled.
However, during development, you might
want to fetch and activate configurations
very frequently to rapidly iterate as you develop and test
your app.
To do this, you can temporarily set it to a low number,
decreasing the amount of time between each fetch.
The settings should be used for development only,
not for an app running in production.
If you're just testing your app with a small 10-person
development team, you are unlikely to hit
the hourly service-side quota limits.
But if you push your app out to thousands
of test users with a very low minimum fetch interval,
your app would probably hit this quota,
and we wouldn't want that.
So that's it.
Remote Config can help you change and customize your app.
And through making parameters on Firebase console
for specific audience groups by using conditions,
you can fetch parameter values in your code to change values
based on your user.
And these same parameters can be used for A/B testing
and personalization with just one or two more lines of code.
The Remote Config JavaScript SDK is open source on GitHub,
so feel free to check that out.
And there are more Firebase fundamentals videos
if you enjoyed this one.
Happy coding.
[MUSIC PLAYING]