THOMAS BOULDIN: Hey, welcome to #AskFirebase.
I'm Thomas Bouldin.
[MUSIC PLAYING]
JEN PERSON: How's it going, Firebase developers?
Welcome to another episode of #AskFirebase, the show
where we answer your burning Firebase questions.
I'm Jen Person, your host, and today my co-host
is Thomas Bouldin.
Tell our viewers about what you do here.
THOMAS BOULDIN: So I joined Firebase a couple of years ago.
And there's this upcoming part called Cloud Functions,
and we wanted to get the Realtime Database in it.
JEN PERSON: It's been a real game changer for me,
I know, and I think that's definitely
been the case for a lot of our developers.
So let's see what we've got.
Let's answer some questions about it, shall we?
THOMAS BOULDIN: Sure.
JEN PERSON: Cloud Functions for this person
are taking longer than expected.
How performant are Cloud Functions for Firebase
when you do heavy jobs with them?
THOMAS BOULDIN: Cloud Functions is still in beta,
and one of the things we're focusing on are both quality--
like, reliability and performance.
But still, one of the things that's
very paradoxical about Cloud Functions
is they actually do better under heavy jobs
than they do when you're just starting up.
Because Cloud Functions are designed-- like,
the way we can give it to you for free for small usage
is we shut them down when they're not being used.
And they will automatically scale up
to whatever quota limits you set when
they're under heavy traffic.
So when you're developing the Cloud Function,
it might actually be in one of the worst case scenarios,
because each time you hit what we call a cold start.
But what happens is as the machinery kind of keeps
on warming up, you have these machines
that are readily available, and you have many, many more
machines than you would have had had you
built your own infrastructure.
So go ahead and do some tests.
I think you'll be very pleased with results.
But Cloud Functions are actually designed for heavy jobs first.
JEN PERSON: Yeah, and having been there right from
the beginning-- and probably a lot of our developers have
as well, since they first came out in beta--
that cold start has improved tremendously.
THOMAS BOULDIN: Oh, yeah.
JEN PERSON: I mean, what a big difference.
So, here's hoping we continue to see improvements.
But that totally makes sense that that's something
that we can expect to happen.
THOMAS BOULDIN: I mean, hold us accountable.
Our goal is to make sure that we work together
as platform developers and with you
as our customers to make sure that we can come up
with something that really solves your needs.
JEN PERSON: You just have to answer things
that you do all day.
I have the challenging part, which
is reading people's names and tags and just feeling terrible
about screwing it up.
So here we go.
You want to read this one for me?
THOMAS BOULDIN: Sure. @JimmyRobz asks, "Hello, @ThatJenPerson."
JEN PERSON: That's me.
THOMAS BOULDIN: "Should I keep my Firebase service account
secret from my version control system?
Thank you."
#AskFirebase.
JEN PERSON: Yes.
The short answer is yes, absolutely.
Yes.
I've noticed a lot of questions about things
that people want to hide that they don't necessarily have to,
like a public API key.
But this is definitely something where
it's a good idea to keep it out of your version control system.
And luckily, you can use the environmental variables
and functions.config to hide that information.
And there was a great question on Stack Overflow that
showcases exactly how to do this for anyone who's not familiar.
And I'll link to that as well.
Our next question comes from @dchaddportwine,
who wants to know "How should I use Firebase Environment
Configuration to store secret API
keys that Cloud Functions for Firebase
will use for JWT authentication?"
THOMAS BOULDIN: OK, so I think there's one
of two parts to this question.
Either how do I get it into Runtime Config
or how do I use it once it's there?
For getting into Runtime Config, frankly there's
not really a helper for getting that file
that you downloaded in the control panel
into your Runtime Config.
So currently, you can do copy and paste.
If you just search on Google, you can get a Medium post.
Actually, it has a script for doing this as well.
But this is something that we might
consider adding direct support for in the future.
Once you have it in there, though,
if you, for example, load this as a secret
is your top-level key and then all the other things,
the fields are sub-values in there.
Then you can just say, Firebase Initialize App.
And then in your options, you say Credential
is Firebase.Credential.cert.
And then you pass the value that's in your Runtime Config.
So Functions.config.secret.
JEN PERSON: Nice.
Yeah.
And so we'll also link to an example of that.
THOMAS BOULDIN: It's a bit of a mouthful,
but each piece kind of composes pretty well.
JEN PERSON: Yes, once you see, it's much simpler.
THOMAS BOULDIN: Yeah.
JEN PERSON: And then I just thought,
broadly, we could sort of talk about recently Cloud Functions
for Firebase version 1.0 came out.
And so looking at versions 1.0 and beyond, what
are some differences or improvements that people
might want to know about?
THOMAS BOULDIN: Yeah.
So the one thing that everybody immediately talks about
is the fact that we, after a lot of thought,
changed the function signatures.
This was not an easy choice to make,
but we think it was the right one, because it dramatically
simplified how 99% of people use functions.
The idea is that, frankly, if you already
have some function that you had running elsewhere
that used a data snapshot from the Firebase Realtime Database,
you can just pass that function to the Google Cloud Functions
SDK, and it will automatically work.
Everything that used to use the data types
can be used as a Cloud Function.
We think that that was a really, really good change
in how we design these things.
Now, as part of that philosophy, we also
decided that we were going to get rid of new types per Cloud
Function datasource.
So this is why we got rid of the Data Delta Snapshot
for the Realtime Database.
JEN PERSON: Right.
THOMAS BOULDIN: Because it was really clever
and people liked it, but we felt that if had to be clever
every time we added a new event source,
eventually we were going to screw up.
None of you are going to remember
all these small nuances.
So we decided to go back to basics
and really simplify our approach.
We have one new data type for change
that anybody can use when they want
to have a before and after version of data.
But we now have a style guide that when we add new event
sources, we require those teams to use the same data types
that you use everywhere else.
And I think that that consistency is really
going to pay off.
It makes testing easier, a bunch of things like that.
JEN PERSON: Yes, you're absolutely right that this
was not taken lightly.
And there was a lot of conversation that went into it.
So even though there are some tweaks that developers
are going to have to make to their functions initially,
I absolutely agree as Firebase continues to grow
and we end up with a whole bunch of triggers,
it would be nice to not have to remember different nuances
about how each of them works.
THOMAS BOULDIN: Yeah.
And frankly, you know, we worked together
to update the Function Samples Repo,
and it was very, very easy.
It was very low risk.
JEN PERSON: Yeah, I can attest to that,
because that change happened four days
before I was giving a talk on [INAUDIBLE] functions.
And I was like, oh, really?
I was like, can't you think about my schedule?
But, yeah, so I was on the plane to DC,
and it took me maybe 15 minutes to fix it, if that.
And that's being careful, because it really
is-- it's only a couple of changes to any existing
functions.
THOMAS BOULDIN: Yeah, we didn't really overhaul anything.
So many of the changes are a deeper focus and testability.
We actually almost last minute scrapped some of our testing
ideas when we realized that we had a complicated framework
and we were building another complicated testing framework
on top of it.
And we said, OK, well, what if we instead
tried to more directly expose the thing
you're trying to test?
That way maybe you don't even need our testing utilities
in order to do good unit tests.
And that's why we have the new .run method.
And so now you don't need to know about the possibly
undocumented way that we connect with Cloud Functions
and create these JSON files.
You have just the .run method.
You can pass only the data parameter
if that's all you need.
You don't need to create or understand the event context
unless you use it.
And we really felt this helps make this much easier
to do unit tests for.
And then Lauren Long, who has been on here a number of times,
did a lot of work on creating a fakes module,
so you can actually create dynamic fake events
for your Cloud Functions, if you want to do some unit testing as
well that way.
JEN PERSON: Very cool.
Thanks so much for coming on and answering some questions
about one of my favorite products,
Cloud Functions for Firebase.
Remember, if you have any questions about Cloud Functions
or any other Firebase features, be
sure to list them on social media
with the hashtag #AskFirebase, and you may see them
on a future episode.
And be sure to subscribe to the Firebase channel
so you can check out new episodes of #AskFirebase,
as well as Meet Firebase, and Firecasts, and all
of the special features that we have going on there.
Thanks so much for being on the show.
THOMAS BOULDIN: Of course.
Thank you very much.
JEN PERSON: And thank all of you for watching.
I'll see you on a future episode.
[MUSIC PLAYING]