DOUG STEVENSON: Hey, everyone.
My name is Doug.
And welcome to the first video in the series
about building better code using Cloud Functions for Firebase.
In this series, I'm going to assume you've already
written some back end functions for your app,
and you want to take your code to the next level in terms
of reliability and performance.
In order to do that, it's important to understand
how Cloud Functions works because, as you've seen,
it's very different than your mobile app.
[MUSIC PLAYING]
Have you ever wondered exactly what
happens during the deployment of your functions
and what happens when it receives production load?
These are great questions.
And I'll take some time to unpack what's going on.
I'm sure you're already aware that the Firebase
CLI, by default, will deploy all your functions
at the same time, and all you have to do
is export them from the entry point of your project,
usually a file called index.
So if you export multiple functions from your index
file, like f1 and f2 over here, then you'll
create or update those two functions
when the deployment is complete.
And I'm sure you're also aware that the code you deploy
is duplicated among all your Cloud Functions.
In fact, the entire contents of the functions folder,
except for node modules, is packaged up
and sent with each function during a deployment.
For each function deployed, Cloud Functions
will create a container image that
has everything the function needs to operate like Linux,
Node.js and a variety of native libraries and utilities,
and so on.
All of the dependencies from your package.json
are installed as well.
This container is ready to run on a new server instance.
Since each container has a copy of everything
from your functions folder, all of your functions
have access to everything in there.
It's a good way to share data and code among your functions.
However, one thing that might not be obvious
is the fact that each of your exported functions
runs in complete isolation from each other.
Here's how that works.
When an event occurs that triggers f1,
Cloud Functions will spin up a server instance
with the container image for f1 and deliver the event to it,
and this instance will hang around
for a while to receive more events for f1 received one
after another in the serial.
When an event occurs that triggers f2,
Cloud Functions will spin up a completely different server
instance for it and deliver its events there.
The instance that's running f1 knows nothing about f2 and vice
versa.
They're completely isolated from each other.
This means they don't share any memory or local disk
space even though they contain all the same code.
You should also know that each function also scales
independently as well.
So f1 could be handling a higher load with many instances
while f2 may not need as many.
Now let's look at just f1.
The server instances executing f1
are also completely isolated from each other.
You could have several invocations of f1
all running at the same time in parallel on multiple instances,
and they know nothing about each other.
They're just each grinding away on their own series of events.
There are two important things to realize about this isolation
between instances.
First, optimizations such as memory and disk caches
are not as effective in Cloud Functions
as they might be in your mobile app,
and not just because of isolation but also the fact
that instances will be shut down outside of your control
without warning.
Second, you might have to do something
to make sure it's safe for your function
to execute in parallel like this if it
accesses external resources.
There's one more important thing to know
about the events going to your functions distributed
to all of its instances.
The events might be processed in a different order
than they were generated.
And for background type functions,
it's also possible that the event
could be delivered more than once, but that should be rare.
These behaviors could have a pretty big impact
on how you write your code.
To sum up, the core behaviors of Cloud Functions
that may affect your code are the following.
First, within each server instance,
events are processed by a single function in serial, one
after another.
Second, if your function scales up to multiple instances,
the function may be executing in parallel
among each of those instances.
And third, events may be processed out of order
and possibly duplicated.
Understanding these behaviors of Cloud Functions
is just the beginning.
In the rest of this series, I'll talk about some practical ways
to deal with the way Cloud Functions works in order
to make your code more robust.
So be sure to subscribe right here to the Firebase channel
on YouTube to get notified when the next video is ready.
And I'll see you here next time.
[MUSIC PLAYING]