[MUSIC PLAYING]
THOMAS BOULDIN: Hi.
My name is Thomas Bouldin, and I'm the engineering lead
for serverless product at Firebase,
such as Cloud Functions for Firebase and Firebase Hosting.
And this is Sogi.
Sogi is a full-stack developer who
wants to build her own social network inspired
by Sparky, the Firebase mascot.
Her network, Sparkle, lets people leave sparks of insight
across the internet.
Today, we're going to see how Sogi can use Google Cloud
Platform, Cloud Functions for Firebase,
and Firebase extensions to build a production-ready application
faster and easier.
So, first, let's talk about Google Cloud Platform.
Google Cloud Platform has released Cloud Functions
Generation 2, which reimagines Cloud Functions
as a transparent layer on top of Cloud Build, Cloud
Run, and Eventarc.
Now this has many benefits to customers.
First and foremost is that Cloud Run supports
many requests per instance.
By serving more requests with fewer instance,
you have performance savings, because using fewer instances
means you'll have fewer cold starts.
A second benefit of concurrency is cost savings.
Let's imagine that Sogi is going to handle three
150-millisecond requests that land 60 milliseconds apart
from each other.
With Cloud Functions Gen 1, this would
hit three different instances, which
would each get a 200-millisecond build for a total of 600
milliseconds.
With Gen 2, you pay for the instance being active,
regardless of how many requests are
being served at the same time.
So this means her active span is rounded up to 300 milliseconds.
Even with light concurrency, that's a 50% savings.
Now concurrency is only available to functions
with at least one full CPU, which, by default,
would be a 2-gigabyte function.
However, at Firebase, we've done some cost forecasting
and believe that for the vast majority of customers,
it's more cost-effective and performant
to give you one full CPU for all Cloud Function sizes.
This will raise the price per millisecond of your functions,
but we believe this is the right choice for the vast majority
of our customers.
If, however, this isn't the right decision for you,
look at our documentation for how to reverse this decision
and go back to the pricing that you had with Gen 1,
but just without concurrency.
Now concurrency also has another benefit to Sogi,
because, you see, Sogi gets bursts of traffic all the time
and she wants to tell Google to reserve
a minimum number of instances to be able to serve traffic
at a moment's notice.
Because Sogi is using the default concurrency
value of 80 requests per instance,
she only needs 1/80 as many min instances
to handle the same amount of traffic.
But Sogi is a Firebase user.
So how is she going to use Cloud Functions Gen 2?
Well, today, we're releasing Cloud Functions
for Firebase's V2 API.
It feels more natively JavaScript.
It supports new event providers.
And, most importantly, it supports Cloud Functions Gen 2.
Let's take a look.
First, you'll notice that the V2 API is available
at firebase-functions/v2.
We packaged both APIs within the same SDK
because we support codebases that target both versions.
This allows you to test out Cloud Functions in the V2 API
without having to rewrite your existing codebase.
Now if we look at https functions, they look the same--
functions.https.onRequest.
However, in the V2 API, we can do deep imports.
So let's clean that up a little.
Now in V1, all functions were configured
with the global runWith command.
Because runWith was available for all functions,
we only allowed you to customize generic features
applicable to all types of functions.
But in Gen 2, functions are modified with a prefix
to the callback.
This options object is now in the context
of your V2 function, which means we
can offer much more nuanced features to be configured.
Let's take a look at an https function
that will override both memory and use CORS.
In V1, we had no CORS option, because CORS
didn't apply to all functions, so you
had to use the CORS middleware yourself.
In V2, we support both memory and CORS
with one command-line option.
Are you tired of using the same options over and over?
Well, starting in V2, we know how
the setGlobalOptions command.
Here, we've applied memory, region, and concurrency choices
to all V2 functions in our codebase.
And the V2 codebase lets you add complexity progressively.
Here's an ObjectFinalized function.
ObjectFinalized happens whenever an object in Cloud Storage
finishes being uploaded.
Here, we have the simple form where
we're listening to the default bucket for our project.
Or we can add one more parameter to specify which
bucket we want to listen to.
If we have complex needs, we can replace that with an options
object and now we specified both the bucket and the timeout.
Finally, you'll notice that, in V2, there's
a single parameter to callbacks.
That's because in the V2 API, we now
use Cloud Events for a more industry-standard format
and more portable code.
So, Sogi says, check out the new V2 API
in the Firebase Functions SDK.
Now Cloud Eventarc is the event backbone
of Cloud Functions Gen 2, which will
let us add new event providers.
Today, I'm proud to announce the first new event
provider, Firebase Alerts.
Firebase Alerts powers the notifications
you get in the Firebase Console, as well as
the emails you get regarding changes in your project.
Through Firebase Alerts, we've now
added functions for Crashlytics, app distribution, and changes
to your project's billing settings.
And Sogi thinks you should use this to automate your business.
For example, Sogi wants to page her on-call DevOps engineer
whenever an issue or a crash that was previously closed as
fixed in a version of her application
shows up in a new version.
She knows she can do this with the onRegressionAlertPublished
event for Firebase Crashlytics.
She also knows that she can add SMS capabilities
to her project with the Send SMS with Twilio extension.
And, starting today, she can even test that code locally,
because today, we've added extension support
to the Firebase Emulator Suite.
It's so easy that Sogi has another tip.
Use Firebase extensions to add capabilities to your project.
Now Firebase extensions are getting
even better with the addition of a new preview feature--
custom events.
Custom events are an upcoming feature
to Cloud Eventarc, which are being offered
to Firebase customers early.
With custom events, you can now listen
to changes that happen in your Firebase extensions
and react to them with a V2 Cloud Function.
For example, Sogi wants to offer a premium version of Sparkle
called Sparkle Orange.
She knows she can process payments
for Sparkle Orange using the Run Payments with Stripe extension.
This extension will automatically
annotate the tokens for all user sessions
with the subscription that they have,
which means Sogi can use Firebase rules to lock down
premium features to paying customers.
However, Sogi wants to help users keep
their subscriptions active.
So she knows that the Run Payments with Stripe extension
now publishes the custom event stripe.invoice.v1.payment
failed.
By listening to this event in a V2 Cloud Function,
she can now notify the user that a payment has failed
and the issue needs to be addressed to avoid
a lapse in subscription.
Sogi says, use custom events to add features
to your extensions.
Now Sparkle Orange is getting popular,
but Sogi wants to improve adoption further.
She's decided that she can improve adoption
by offering new customers of Sparkle a free trial.
Sogi uses the new blocking auth functions
for Cloud Functions for Firebase.
Blocking auth functions allow her
to customize behavior-- either a user account being created
or a session when the user logs on.
Here, she listens to the beforeUserCrated event
so that she can modify the claims that
will be minted for this user to include an expiration
date of their free trial.
Now she can use Firebase rules to lock down
these premium features to be available to either customers
who have an active subscription or who are still
enjoying their free trial.
Now Sogi says, use blocking auth functions
to customize user management.
Now let's talk about another set of advanced features available
for both Gen 1 and Gen 2 users, .env files and Cloud Secrets
Manager.
With Cloud Secrets Manager, Sogi can
keep API keys and other sensitive information
outside of her function source code
and outside of her function definitions.
With .env files, she has an industry-standard way
of applying environment variables to her application.
.env files also support project overrides.
Let's imagine Sogi has a project with a prod alias
and a project with a staging alias.
She can keep common environment files in a .env file.
Meanwhile, she can put environment variables for her
production application in .env.prod and for her staging
application in .env.staging.
Also, if she wants to override the behavior of her local
emulator, she can modify .env.local.
So let's see where Sogi uses this in practice.
Blogs and news articles have started embedding Sparks
into their websites and Sogi wants to encourage this.
So she's added an SDK and an API that
helps people embed Sparks inside a website.
She wants this API to be fast, faster
than a database read fast.
So she is going to use Firestore Bundles.
Firestore Bundles let us package the results of a query
and deliver it to a client, who will then deserialize
those results and use them without having
to query the backend.
Because Sogi wants this to be lightning-fast,
she's actually going to store saved queries
in Cloud Memorystore for millisecond-level latency.
Cloud Memorystore will be installed in a Virtual Private
Cloud, or VPC.
She can then access that VPC inside her Cloud Function
using a VPC connector.
This means that the Redis API of Cloud Memorystore
will be accessible to her function over a private IP
address.
She puts that private IP address and port in her .env.prod file.
However, Sogi chose to use Cloud Memorystore and the Redis API
because Redis is open-source software that she
can install locally.
Sogi uses this to install a local copy of Redis on her
machine and puts its address in her .env.local file.
Now when Sogi launches the Firebase Emulator Suite,
her emulated Cloud Functions can talk to her Redis application
and her program can work seamlessly, both in development
and in production.
So Sogi says, "Keep secrets private with Cloud Secret
Manager and use .env files to change the way code behaves
across projects."
Now, Sogi wants to improve adoption
by sending a throwback email.
Once a year, Sogi wants to send an email
to all of her customers that help remind them
of the communities with which they've engaged.
Sogi knows that she can send these emails with the Trigger
Email with SendGrid extension.
However, she also knows that SendGrid has a 600
request per minute API limit.
But Sogi has millions of users, so how can
she possibly send all those emails?
Well, Sogi does this thanks to our new partnership
with the Cloud Tasks team.
Cloud Task queues are great at throttling
large bursts of traffic.
So she can use a Cloud Task Queue function to enqueue
these millions of API requests.
And, by setting the maxDispatchPerSecond field,
she never has to worry about rate limits again.
Sogi says, use Task Queue functions to handle
large bursts of traffic.
Now Sogi's getting rather sophisticated.
She's hired multiple team to manage
multiple features of Sparkle.
She can now use the new codebases feature
of Cloud Functions for Firebase to manage
separate parts of code that are each tightly coupled.
By using codebases, she can keep different parts
of functions in different directories
or even different source repositories entirely.
And soon, the Firebase command line
will even recognize if a codebase hasn't been modified
since last deploy and skip it during Firebase deploy
thus improving the speed and reliability of CI/CD pipelines.
So Sogi says use codebases to manage decoupled code.
With that, let's take a look back at all the tips
Sogi has given us to make a production-ready application
faster and easier.
She said, "Use concurrency min instances
to manage capacity and costs.
Check out the new V2 API in the Firebase Functions SDK.
Use Firebase Alerts functions to automate your business.
Use Firebase extensions to add capabilities to your project.
Use custom events to add features to your extensions.
Use blocking auth functions to customize user management.
Keep secrets private with Cloud Secrets Manager.
Use .env files to change the way code behaves across projects
and in local emulation.
Use Task Queue functions to handle large bursts of traffic.
And use codebases to manage decoupled code."
With that, she and you are both ready to create
production-ready applications faster.
Thank you very much.
[NON-ENGLISH SPEECH]
Have a great day.
[MUSIC PLAYING]