Building Modern Web Apps with Firebase App Hosting and Google Cloud

Hi everyone. I'm Julia. I'm a product manager for Firebase. And I'm Thomas, a software engineer for Firebase. So

Julia, what are we doing here today? We're talking about building web apps, of course, specifically building great

web apps with Firebase. Now, as a product manager, I talked to a lot of customers who are looking for a modern

platform for end-to-end web development. And no matter the type of app they're building or the size of their company,

there's always one thing these customers have in common. Businesses of all sizes are constantly seeking ways to optimize

development cycles and reduce time to market. This is where Firebase comes in. Firebase provides a platform for rapid

app development backed by Google Cloud. While our primary focus today is Firebase app hosting, building full

stack web apps often requires more than hosting. That's why we're excited to show you how app hosting connects with

the rest of Firebase and Google Cloud to provide a unified serverless platform for all your applications needs.

Today's demo will bring this to life, showcasing integrations with Firebase authentication, data connect, Genkit,

the Gemini API, and Cloud Memory Store. By the end of this talk, you'll understand how to use Firebase to

accelerate building and deploying modern, full stack, and AI web apps to Google

Cloud. Let's start with an overview of what Firebase is. If you're building a web app, you'll

likely need authentication, a database, and storage. Traditionally, that means building and managing your own back-end

server. Firebase simplifies this. It's a serverless platform with authentication, database, storage, and more services

built on Google Cloud. We provide web and mobile client SDKs so your front end can talk directly to

Firebase and then Firebase securely interacts with the underlying cloud services, enforcing security rules that

you define. You also need a backend to serve your web app and for specific tasks like

processing payments or rendering pages on the server with Nex.js. Firebase App Hosting offers serverless

web hosting for the entire stack and the Firebase Admin SDK lets you access those same cloud services from your trusted

back-end environment. And these days, if you're building a web app, you're probably

thinking about how you can use generative AI to improve your app's experience.

Genkit is a serverside framework that makes it easier to add generative AI features into your app. But more on that

later. Let's dive into Firebase app hosting. Firebase app hosting is a git ccentric serverless hosting solution for

modern web frameworks. App hosting manages the entire stack for your web app from the build pipeline to the CDN

to serverside rendering. When I say modern frameworks, I'm talking about full stack JavaScript

frameworks like Angular and Nex.js. These frameworks make it simpler to get the benefits of serverside

rendering. Things like improved SEO and faster initial load times with the ease and familiarity of the tools we use to

build frontends. But because these frameworks need a server, deploying an app isn't as simple

as throwing a couple static files up on a CDN. You need a backend, but you also need a build environment for static site

generation, and you still need a CDN for caching content. You need it all. With app hosting, you don't have to worry

about any of that. Apposting manages the entire stack for you. I believe the best way to understand its

value is to see it in action. So, let me walk you through the app hosting developer experience showcasing all the

exciting new features we've been working on. You can get started with app hosting by deploying one of our sample apps.

Just run npm innit app hosting to download our templates for Angular or Nex.js.

Now I'm going to push this source code to GitHub because I want to leverage app hosting's Git integration for continuous

deployment. Cool. I'm ready to go to the Firebase console and set up app hosting. Select app hosting from the

left nav. Then click get started. Choose a primary region for your app. It's best to choose a region

close to where your users are. Now sign into GitHub to install the Firebase app hosting GitHub app on your

account. Once your account is connected, choose the repo that contains your web app. Then select a branch for automatic

rollouts. Whenever changes are pushed or merged into this branch, app hosting will automatically roll them out to your

live site. Let's pick main. Finally, name your backend and

deploy. In just a few clicks and without leaving the Firebase console, you now have an entire stack set up in Google

Cloud for building and deploying your web app with CI/CD enabled for your main branch. So, what's happening behind the

scenes? App hosting is running your framework build in cloud build to generate static

assets and create a container image for cloud run. Then app hosting deploys that container image to cloud run behind a

managed CDN and networking layer. Right off the bat, apposting provides a default domain for your app

with DNS certificate management and load balancing all set up. And if you have your own domain you want to use, you can

add a custom domain in your backend settings. In the settings tab, you can also confirm that automatic rollouts are

enabled for the connected repo and main branch. Once the roll out finishes, we can visit our new URL to see the

deployed app. Looks great. I'm going to switch to an existing app

with more data so we can do a quick UI tour. This is another one of our Angular templates. This time for an e-commerce

app. Front and center, you have the new backend overview page where you get a summary of the live rollout, the latest

attempted roll out, and your app's traffic and health for the last seven days.

You can view request count by response code with markers for each roll out to help identify if a particular change

correlates with an increase in error rates. If you click on the errors link, you'll find runtime logs filtered for

client and server errors in our new logs viewer. In the usage tab, you can now view CDN usage metrics in addition to

Cloud Run. This is helpful for understanding how many of your app's requests are served from the CDN cache

so you can identify opportunities to improve your cache hit rate. These charts have those same rollout markers

so you can see if a particular rollout is impacting caching behavior or causing an increase in compute utilization.

Speaking of compute utilization, you can inspect the underlying cloud run revision for each rollout to see your

app's runtime configuration. Things like CPU, concurrency, min instances, and environment

variables. If you want to change any of these settings or add environment variables to your app, you can do so in

a config file called app hosting.yml. Notice this environment variable called Firebase

config. This is important if you're using other Firebase services in your app. It's used to initialize the

Firebase SDKs with the right project information to ensure your app is talking to the right project

services. If you've built web apps with Firebase, you've probably copied and pasted the Firebase config object more

times than you can count. But guess what? Apposting now automatically sets this environment variable for you, so

you don't have to manually configure it. Besides being convenient, it allows you to safely deploy the same codebase

across many environments, preventing your staging app from accidentally accessing production data. This works in

both the admin and client SDKs. For the client SDK, the config is baked in at build time with a new environment

variable set by app hosting called Firebase web app config. You'll see this in the cloud build logs. All right, you

may have noticed on the backend overview that my latest build failed. Apposting now surfaces build error messages in the

Firebase console, so you don't have to dig through logs in Google Cloud to figure out what went wrong.

Looks like my build failed because of a missing lock file. It's best practice to have a lock file in your project to

ensure consistency and reliability in your development and deployment workflows. Well, that's no problem. All

I have to do is run npm install in my project and then push the generated package lock JSON to GitHub.

Because I have automatic rollouts enabled, app posting immediately creates a new roll

out. Looks like that fixed the issue. The roll out finished. Let's check it out. Oh no, we have a problem. I've

accidentally applied a 50% discount to all products instead of a select few and I made the background pink. This is

off-brand and I need to roll back immediately. In the rollouts tab, I can roll back to a previous version of my

app without rebuilding. Skipping the build leads to a faster recovery and ensures consistency in

generated static content. During build time, your app may generate static pages that depend on data outside of source

control, like your database. This means that the same commit can produce different outputs if production has

changed. Reusing the previous container image instead of rebuilding guarantees that

the previous stable state is restored irrespective of changes to data sources outside of your

code. Phew, we're rolled back. And by the way, you may notice this app has an instantly interactive UI because it's

using Angular's latest incremental hydration. Okay, let's recap what you just saw. App

hosting accelerates time to market by managing your entire stack and offering seamless integration with GitHub for

automated deployments. You push to GitHub and app hosting figures out the rest.

Many of the services used for building and deploying the app such as cloud build, artifact registry, cloud run, and

a few more are installed in your project. But the networking layer is our secret sauce. We manage our own

instances of Google Cloud Load Balancer, CDN, Certificate Manager, and DNS in a Google managed tenant project, which

allows us to provide scale to zero pricing. You pay for the networking you use with no minimum spending

amount. You also saw some of the new features we've added since our preview launch last year. Designed to boost your

productivity. You can now quickly diagnose and resolve build failures with our improved, more informative error

messages. You can now recover from production incidents in seconds by using App

Hosting's new monitoring dashboard to understands your app's performance and health and instantly roll back to a

previous version if you spot a regression. And app hosting now makes it simpler to juggle multiple environments

by automatically configuring the Firebase admin and client SDKs. But that's not all that's new.

We're excited to share that Firebase app hosting is in general availability with support for Angular and

Nex.js. Being GA means app hosting is ready for production use. And guess what? You can now deploy next and Astro

apps to app posting as well. These framework integrations are in preview. All right. So, you've seen how

app hosting enhances productivity by providing a simplified developer experience for full stack app

development. Now, let's address the need for control. Thomas, what options do developers have to tailor app hosting to

meet their specific needs? App hosting is an opinionated but also flexible framework. You can

customize app hosting to meet your app and business needs. We provide smart defaults for Cloud Run, but you can

customize your back-end configuration. Things like concurrency, CPU and memory limits, min instances, max instances

depending on your app's compute needs. We also support granular environment configurations.

Not only can you define multiple environments for the same codebase, you can control where each environment

variable is used either at build time or runtime. This gives you more control over how your secrets and data are being

handled, ensuring they aren't accessible in more places than they need to be. Since we launched the preview of app

hosting last year, we've made the product even more flexible and customizable.

We now have regions available in the United States, Europe, and Asia to ensure your app is served from a region

close to your end users. We're excited to share that you can also now connect app hosting to a Google

Cloud VPC network, enabling you to augment your app stack with more back-end services such as a cache, a

database like cloud SQL or Spanner or even microservices implemented on compute engine or

Kubernetes. Finally, you can now customize your app's build and start commands.

App hosting infers how to build and run your app based on the detected framework. But if you need a custom

build or start command, you can now override our smart defaults. Enhancing app hosting's

flexibility is just one aspect of our commitment to making it a robust solution for enterprise level

applications. App hosting is built on enterprise ready Google cloud services and is prepared to

scale with you as your business grows. There are three ways your hosting solution needs to scale with you. First,

the infrastructure needs to be able to handle a sudden influx of traffic without negative performance impacts on

your customers. Second, your costs need to scale. And third, it needs to be secure

from the start so that when your business needs evolve and security requirements become more defined, you

don't need to refactor your code to meet your business's new security standards. Apposting checks all of these

boxes with automatic scaling with cloud run, scale to zero pricing, and enterprisegrade secrets management.

That's fantastic to hear, Thomas. Streamlined development with options to customize and scale are exactly the

types of things our customers are looking for. I hear a lot about customers business requirements

firsthand. So let's put app hosting to the test and explore how it addresses some of these realworld use

cases. I have a customer building a modern e-commerce application with Nex.js.

This app needs to securely connect to payment providers, provide a personalized experience with user

profiles. It needs a great product search and review experience. It needs to be fast, and it needs to be high

quality with local and pre-production environments set up for testing. Thomas, can you walk us through how we'd achieve

all of this with Firebase? Sure. I love working with customers and finding ways to solve their problems.

Let's work through these requirements one at a time. Starting with securely connecting to payment

providers. Stripe is a great payment provider. It handles complex regulations for you so you can handle the business

of managing a storefront. If you're using Stripe, you need an API key, and it's important to lock down access to

those API keys to prevent unauthorized use. With Firebase App Hosting, you can store API keys as secrets using our

streamlined integration with Cloud Secret Manager. With Cloud Secret Manager, you can securely store

sensitive values and control who has access to them. Here we've created a secret value for our Stripe API key that

can be referenced in our code. Nobody in the organization can read this secret unless explicitly

granted permission and of course their storefront is going to have personalized

information. By adding user profiles and authentication to your app, you can give your users a faster checkout experience

with saved payment information, show their order history, and provide personalized

recommendations. Firebase authentication has long been a great solution for creating user accounts and managing

access. Over the last year, we've made some key improvements in the way modern full stack web applications can use

Firebase off. In a full stack web app, you have a client and server and both need to be able to send user

authenticated requests. For example, you may want to render a page on the server if it needs data from various sources

because it's more performant for all of those requests to happen at once before you send the result back to the user.

Traditionally, you'd need to use the Firebase Admin SDK for serverside requests, but because the Admin SDK

bypasses security rules, coding bugs could lead to vulnerabilities and leaking user

data. Now, you can run with the client SDK, which requires security rules, on the server, providing it with manual

user tokens. This gives you the best of both worlds. You can code server side but with

defense and depth protection against leaking or altering private user data. So now we're able to safely send

user authenticated requests from the server. But this introduces another challenge. If your application has a

combination of client and server rendered components, it can be troublesome to synchronize off state

between client and server. The good news is our latest SDK can do this automatically on Firebase app hosting.

The latest SDK has a preview release of cookiebased off synchronization so that your client credentials can be fetched

server side. All right, let's talk about how to provide a great search experience in

your app. Every storefront owner wants to help customers find the product they're looking for. Back in the day, we

might have enabled this with a literal text search. But the advancements in large language models have enabled us to

do much more. Firebase data connect supports similarity search. At the core of this

feature are vector embeddings which are arrays of floatingoint numbers representing the semantic meaning of

text. To use this in your Nex.js e-commerce app, you first create a schema for your products table that

includes things like product ID, description, and a new field of vector type to store vector embeddings.

Then when your app updates or fetches products from your database, data connect automatically adds vector

embeddings for semantic similarity powered by the Vert.Ex API. When your customers search for

products, your app queries for products using vector similarity. This way, your customers can easily discover all

relevant products, even if they aren't an exact text match. A lot of times customers scan the

average rating of a product, but they also want to know the highs and lows of user reviews. While some buyers are

patient enough to read through a long list of reviews, modern storefronts help buyers make snap decisions with review

summaries. Genkit and the Gemini API can help us out. Genkit is a serverside framework for interfacing with

generative AI models with GA support for NodeJS and alpha support for Python. A key benefit to using Genkit to

integrate models into your app instead of interfacing with those models directly is you are coding against a

common abstraction which lets you drop in new models without refactoring your app.

Genkit comes with a UI playground to help you tinker with prompts and models and parameters until you get the AI

responses you're looking for. Genkit also gives you monitoring and tracing insights in the Firebase console. The

most common primitive of Genkit is a flow which represents an AI powered workload. In our e-commerce app, we can

create a flow that queries data connect for reviews of a particular product and then feeds them into any model. Here

we'll use Gemini for a ragbased summary of the reviews. Up next, we have caching to

improve application performance. Several studies have shown a link between increased latency and decreased revenue.

Let's quickly add a cache to our system. Generative AI is much slower than many other types of APIs, and product review

summaries only need to change when there's a new review. We've already improved responsiveness thanks to

Genkit's seamless support for streaming, but we can do better. Using Firebase app hosting's new support for VPC access,

our app can now talk to Cloud Memory Store, which is protected by a VPC perimeter.

We can modify our genkit flow to check for cache results and store newly generated results into the cache.

Whereas our API for inserting a new product review will include a cache purge upon writing the new data.

Alternatively, if we didn't need results quite so fresh, we could instead allow caches to expire and regenerate via a

TTL. This lets us serve results faster with fewer calls to AI APIs in production.

And like any serious app, we should have a staging tier in addition to production. App hosting is flexible with

many ways to achieve this goal. You can have multiple backends pointing to the same repository within the same project,

but a more professional solution would be to use different projects, each with their own backend.

This helps ensure that bugs and staging cannot alter production data. Using multiple Firebase projects is easy

thanks to automatic project initialization. Simply call initialize app with no parameters and your Firebase

app hosting backend will autoinitialize for the current project. Automatic initialization works

both server side and client side on Firebase app hosting. If you have other resources that need to be specialized,

Firebase app hosting has the concept of environments, you can label one backend as the production environment and

another as the staging environment. By doing this, each backend will look at either

apposting.production.yaml or apposting.staging.yaml to override configurations from apposting.yaml YAML

and either production or staging. When it comes time to make your changes live, there are multiple

strategies available to Firebase app hosting. You could point both backends to the main branch on GitHub, but only

enable automatic rollouts on staging. Or you could have a separate production branch which allows you to cherrypick

bug fixes out of order to minimize risk in the rare case that rolling forward is appropriate. And of course, it's much

easier and faster if you can test code locally before creating a pull request. Let's walk through our

architecture for local development. Firebase app hosting, data connect, and authentication are run through the

Firebase emulator suite. Genkit is simply an SDK, so it can obviously run anywhere your code runs. Since our

customer is using the Memcache API for cloud memory store in production, they can install memcache on their local

machine. For their Stripe connections, they can create a sandbox and use the Stripe CLI to simulate web hooks. We can

configure the app hosting emulator to talk to our local instances of memcache and receive callbacks from the stripe

CLI instead of production. We'll use the production Gemini and vertex API keys since they're

readonly APIs. All right, Thomas, this all sounds really great, but I've had enough with

the architecture diagrams. I want to see this in action. Can you show me an app you've built with Firebase that does all

these things? Okay. Like any good demo, I'm going to start by showing you on my local

machine. Since Julia already showed you app hosting's production features, I'm going to focus this demo on the emulator

suite. Before we dive into the emulator though, let's take a look at my app hosting.yaml for production.

You can see that I've used VPC direct connect in order to access my default VPC network. I'm also connecting to the

memcache API for cloud memory store on a local internal IP address. Now let's go ahead and start

initializing the emulators. For simplicity's sake, I'm going to focus just on the initialization of the

app hosting emulator. It's asking me for my root directory and then tells me about that

apposting.yaml file where I can override settings for local development. Let's go ahead and create it.

I need to override my memcache address to point to my local machine. And I'm also going to need to override the

Stripe web hook secret in order to use the Stripe web hook emulator. My production application is still using a

Stripe sandbox, so I don't actually need to overwrite that. Now, in a previous runrough, I've

already created this secret. The CLI has noticed this and allows me to reuse it. Now it's asking me who should have

access to these secrets for local development. I can provide either a user or an email group. Since I've already

created an email group for my developer team to talk to each other, let's go ahead and use

that. It's granted permission to the secret I overwrote, but it also granted access to secrets where the emulator is

falling back to apposting.yaml. To get started, I'm going to run three processes. I'm going to launch the

Genkit CLI and pass it the Firebase emulator suite. This lets the Genkit UI see what's happening in my emulated app.

Next, I'll start the Stripe web hook emulator and point it to my app. Memcache is already running as a Damon.

Now, let's check out that beautiful app. First, I'm going to try out search. Let's search for a

suit. You'll see that suit is the first result, but related terms like blazers also show up. Let's go ahead and check

out that suit. I'm going to scroll quickly to the product reviews to see that summary stream

in. Now if I refresh and use memcache, you can see that the full results are faster than even the first bite while

using streaming. Now let's jump into the Genkit UI to play around a bit. Here you

can see the model playground. My app installed the Google AI extension, so I have the ability to

play with all of Google's models. Let's try a quick experiment and see if this model and parameters give me the

right balance of speed and [Music] accuracy. Let's jump to the flows view

and play with my summarize reviews flow. I'm going to grab the product ID from that site and pass it into the

function. I'll leave for force refresh on and run a streaming response. Now if I turn force refresh

off, I can see that the results come almost instantly. Let's dive into that in the traces

view. If I look at the original call, I can see that I fetched data from data connect called the generate API to do a

ragbased summary and wrote it to the cache. This took 734 milliseconds. Meanwhile, if I jump to the second call,

it found it in the cache and was able to return in only 4 milliseconds. I saved 730

milliseconds. Let's go back to the app. This suit looks good, so I'm going to go ahead and buy

it. It looks like I need a user account in order to buy the suit. So, let's go ahead and create one.

[Music] [Music] Now, while this is happening, pay

attention to this command line prompt. And you can see all of the Stripe web hooks running. This is actually running

against a live sandbox environment. Great. I've bought my suit and I can view the

order. Now, this page is actually rendered server side, yet I'm still able to get customized information from

Firebase Data Connect. This is because we're using off synchronization and the new Git server app API. But now, let's

go to production. I've done an initial deployment of my app and I can see it live.

But if I go to the data connect dashboard and run the get all orders query, I can see that there were no

orders. My emulation did not poison production data. Similarly, the off dashboard shows no users.

But I can go to the Genkit dashboard because I've used the Firebase plugin and run enable Firebase

telemetry and I can see the history of Genkit in my application including that latency dropping because of caching.

Let's dive into the summarized reviews flow again. Again, I can see a strong

difference between cases where I was and was not caching. I can see the input and output of a flow

that I checked the cache batched reviews from data connect called generate for a ragbased summary and wrote to the cache

taking a total of 635 milliseconds. Meanwhile, a cache response only took 1 millisecond in

production. So that was our demo. To recap, Firebase app hosting has rich features to help you get to market

faster, all powered by Google Cloud's global scale services. As you build your project, you can use the emulator suite

to run most of your code locally, including secure local config that's safe to share with your dev team.

Publishing your site is as easy as pushing to GitHub where we'll kick off a build and report statuses back through

GitHub checks. Your application does not need to hardcode project information with Firebase SDK

autoinit. Our networking layer includes cloud CDN for faster response times and VPC access to extend your app with

internal services like cloud memory store, cloud SQL, cloud spanner or microservices built on compute engine or

Kubernetes. Our metrics dashboard lets you see the most important information about your site at a glance. And if you

see a problem, instant rollbacks let you quickly restore good state without rebuilding, which could create a

different version if you statically render pages based on external data. But wait, that's not all. We're actually

sneaking in a few more updates today for Firebase app hosting. We're constantly improving app hosting to make it easier

for developers to build and deploy modern web apps. Since launching general availability last month, we've added the

ability to deploy from local source with Firebase deploy, giving you more flexibility in how you deploy to

production. We also now have automatic configuration for the Firebase SDK in the emulator so that when you run your

app locally, it automatically uses emulated Firebase services instead of production.

And finally, you can now deploy apps from Firebase Studio to app hosting with the click of a

button. Okay, now I think we're ready to wrap up. Whether you're building with

Angular, Nex.js, Next, Nitro, or any other Node.js application, Firebase provides a robust yet streamlined

experience for deploying, managing, and scaling your web app. Get started with one of our sample apps today by running

npm andnit at apposting. If you have any feedback or feature requests, let us know on

uservoice. We'd love to hear from you. On behalf of Thomas and myself, thank you for watching.

[Applause]