FRANK VAN PUFFELEN: I work with developers
who build apps on Firebase.
And as their apps grow, they often
add Google Cloud components to their app.
MARTIN OMANDER: And I've done the same myself.
The first few versions run on Firebase alone,
and over time, I tend to add Google Cloud features.
FRANK VAN PUFFELEN: OK, so let's have
a look at what developers might need
as their Firebase app grows.
[AUDIO LOGO]
MARTIN OMANDER: I'm Martin and I'm a developer advocate.
I've had various jobs within Google over the last 17 years,
but now I help developers build great apps on Google Cloud.
FRANK VAN PUFFELEN: And I'm Puff, or Frank,
and I'm a Firebase engineer.
I've been using Firebase since the first beta versions
in 2012.
And I help developers build amazing apps with Firebase.
MARTIN OMANDER: And while we have different titles,
Firebase and Google Cloud are two sides of the same coin,
right?
FRANK VAN PUFFELEN: Yes.
Any Firebase project is just a Google Cloud project
with some extra annotations.
So if you have a Firebase project today,
you already have a Google Cloud project.
See, here we have the Firebase Console
where you manage all of your Firebase projects.
And you can see that I have a project.
Now let's open the Google Cloud Console, and look,
there's the same project.
These are really just two views on the same data.
MARTIN OMANDER: So it makes sense
that developers start using Firebase
and then add components for Google Cloud, or the other way
around.
What Google Cloud features do you
see Firebase developers using the most, Puff?
FRANK VAN PUFFELEN: I often see Firebase developers
using these three Google Cloud features.
More control of server-side code.
They want to do reports on Firestore data.
And they want to handle asynchronous communication
with other systems.
MARTIN OMANDER: All right, let's start
with the first one on your list.
Developers need more control of server-side code.
Tell me more.
FRANK VAN PUFFELEN: Cloud Functions for Firebase
is a great way of running server-side code
for your web or mobile apps.
We really made it as easy as possible
to add server-side code to your Firebase app.
But as your application grows, you
end up with many Cloud Functions.
Once you reach like a dozen or more,
you may want to manage them as a single service
instead of as individual functions.
With Cloud Run, you can do exactly that.
MARTIN OMANDER: After I switched to Cloud Run,
I noticed that there were fewer slow cold starts.
After the first request to my Cloud Run service,
there were no more cold starts for any of the endpoints
within that service.
FRANK VAN PUFFELEN: Yeah, that's a good point.
And also sometimes developers need
to write back-end code in languages other than JavaScript
or Python.
Perhaps they work with a backend team
who prefer another language, like C Sharp, Java, or Go.
Then they can run their own backend in Cloud Run.
MARTIN OMANDER: Right.
Cloud Run supports any language that you
can build a container for.
That means pretty much any current programming language.
FRANK VAN PUFFELEN: Exactly, and with
container-based development, you get better control
of your dependencies because they're on the container
that you control.
MARTIN OMANDER: Yep.
Containers help address the problem
of "it runs on my machine."
FRANK VAN PUFFELEN: Another reason
is that you can include binary libraries in a container.
So you might need a specific binary library
for things like image manipulation, data compression,
or PDF creation.
MARTIN OMANDER: Right.
One of my applications draws dynamic text and graphics
and returns an image to the client.
It was very useful to load fonts into my Cloud Run container.
FRANK VAN PUFFELEN: Oh yeah, I get that.
You just add the dependencies into your Dockerfile
and Google will make them available to your code
and Cloud Run.
MARTIN OMANDER: All right.
That was number one.
The second item on your list was reports on Firestore data?
FRANK VAN PUFFELEN: Many developers
use Firestore to store the apps data on the server.
Now Firestore is a NoSQL database,
which means that it's great for auto scaling
to your number of users.
And it's easy to get started with.
You can look up individual records quickly.
MARTIN OMANDER: I hear a "but" coming.
FRANK VAN PUFFELEN: Yeah, that's right.
Firestore is not great for ad-hoc querying.
So it's not the best solution for calculating
your typical report data, which may require
reading thousands of records.
For example, let's say that you have
100,000 sales records in Firestore,
each in a separate document.
That you want to see how many sales you
had in each region for each week in the past quarter.
MARTIN OMANDER: And that would require reading 100,000
documents one at a time?
FRANK VAN PUFFELEN: Right.
And document databases are just not optimized for that.
And you'd be paying for each of those document reads.
But there are databases that are very good at ad-hoc queries,
like these.
My personal favorite is BigQuery.
MARTIN OMANDER: And how do you now get your Firestore
documents into BigQuery?
FRANK VAN PUFFELEN: Well, there are two easy ways.
You can batch export or you can do streaming.
MARTIN OMANDER: So I think I've used the batch approach.
Every night my application runs gcloud firestore export
to export the data from Firestore followed by a bq load
to load the data into BigQuery.
That's what you mean, right?
FRANK VAN PUFFELEN: Yeah, that's it.
Running a nightly batch job is easy,
but it means that your BigQuery reports may be up to 24 hours
behind the current state of the data in Firestore.
With streaming, your BigQuery data will always be up-to-date.
There's a Firebase extension that sets this up for you.
MARTIN OMANDER: Yeah, I've read about that extension.
I like how I don't have to write any code,
I just have to enable it in my project.
But if I understand correctly, it tracks changes in Firestore.
Will it backfill existing Firestore data?
FRANK VAN PUFFELEN: Yeah.
It includes a script that will backfill
existing Firestore data.
So you turn on streaming, then you
run the import script to backfill the data,
and you're all set.
MARTIN OMANDER: OK.
So once my data is in BigQuery, I can run reports on it?
FRANK VAN PUFFELEN: Yeah.
Some developers prefer to run SQL queries into BigQuery user
interface.
Others prefer to build dashboards in Looker Studio.
Looker Studio supports 40 chart types.
So even I can use it to create beautiful visualizations
on data from Firestore.
MARTIN OMANDER: All right.
Let's talk about the third item on your list,
async communication with other systems.
Tell me more, Puff.
FRANK VAN PUFFELEN: Many Firebase applications
are part of larger systems that are not built in Firebase.
For example, an e-commerce web app
may send orders to an existing legacy backend system.
MARTIN OMANDER: Well, the Firebase app
can just make an HTTP call to that legacy backend, right?
FRANK VAN PUFFELEN: Yeah, it can.
Yeah for sure, but there are a few potential problems
with that.
The Firebase application would need
to know the address of the backend system.
And if that ever changes, you would need
to update the Firebase app.
If there are multiple recipients,
the app would need to know about that too.
And if the HTTP request fails, the Firebase application
would need to retry it later.
All of that is possible, but it adds extra code, right?
And you really don't want to have
that code in your client app.
MARTIN OMANDER: Ah, and that's where the asynchronous
communication comes in.
FRANK VAN PUFFELEN: Exactly.
There's a product in Google Cloud called Pub/Sub
that handles all of this.
So we implement a Cloud Function that you call from your client
side application, and then that Cloud Function queues a request
for the other system in Pub/Sub.
MARTIN OMANDER: Right.
I've written applications that send Pub/Sub messages before.
It was just a few lines of code.
FRANK VAN PUFFELEN: Exactly, that's the idea.
Many customers use Pub/Sub as a robust message
bus between their various Cloud applications.
And Firebase applications can be part of that architecture
because remember, every Firebase project
is a Google Cloud project too.
MARTIN OMANDER: All right.
Now, who can receive these Pub/Sub messages?
FRANK VAN PUFFELEN: Oh, that can be subscribers on Google Cloud
or anywhere on the internet.
They can receive and act on all of the messages.
So you can choose if the messages should
be pushed to the subscriber or if subscribers
should pull the messages.
And you can even let one message go to multiple subscribers.
MARTIN OMANDER: All right, we've covered a lot of ground here,
Puff.
So let's recap.
FRANK VAN PUFFELEN: First off, every Firebase project
is a Google Cloud project.
Firebase and Google Cloud are just
two sides of the same coin.
They work well together.
MARTIN OMANDER: And you work with the developers who
host their apps on Firebase.
Which Google Cloud features do you see them use most often?
FRANK VAN PUFFELEN: They want more control
of their server-side code plus the advantages
of container-based development.
They get that with Cloud Run.
Then they want reports and dashboards
based on their Firestore data.
They get that with BigQuery and Looker Studio.
And they may want asynchronous communication
with other systems, in Google Cloud
or anywhere on the internet, and they
would get that with Pub/Sub.
MARTIN OMANDER: Great recap.
FRANK VAN PUFFELEN: Yeah, that was excellent, Martin.
Thanks for joining me.
MARTIN OMANDER: Thanks for having me, Puff.
This was fun.
FRANK VAN PUFFELEN: And thank you for watching.
Now, if you have any questions about today's topics,
post them in the comments below.
And if you want to learn more about Firebase,
subscribe to the channel and give us
a Like while you're at it.
See you next time.
[AUDIO LOGO]