Building Modern Web Apps with Firebase App Hosting and Google Cloud

[MUSIC PLAYING] JULIA REID: Hi, everyone. I'm Julia.

I'm a product manager for Firebase. THOMAS BOULDIN: And I'm Thomas, a software engineer for Firebase.

So Julia, what are we doing here today? JULIA REID: We're talking about building web apps, of course, specifically building great web apps with Firebase.

Now, as a product manager, I talk 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 Memorystore.

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 backend 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 back end to serve your web app

and for specific tasks, like processing payments or rendering pages on the server with Next.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 backend 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 server-side framework that makes it easier to add generative AI features into your app, but more on that later.

Let's dive in to Firebase App Hosting. Firebase App Hosting is a Git-centric, 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 server-side rendering. When I say modern frameworks, I'm

talking about full stack JavaScript frameworks, like Angular and Next.js. These frameworks make it simpler to get the benefits of server

side 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. App Hosting 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 init at App Hosting to download our templates for Angular or Next.js.

Now, I'm going to push this source code to GitHub because I want to leverage App Hosting's postings 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 in to 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 liv 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, App Hosting 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 rollout 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 rollout, and your app's traffic and health for the last seven days.

You can view request count by response code, with markers for each rollout 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 the 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-- thing 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 apphosting.yaml.

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? App Hosting 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 code base 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.

App Hosting now services 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 Hosting immediately creates a new rollout. Looks like that fixed the issue.

The rollout 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.

OK, 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 launched 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 understand 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 Next.js.

Being GA means App Hosting is ready for production use. And guess what? You can now deploy Nuxt and Astro apps to App Hosting

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? THOMAS BOULDIN: 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 backend 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 code

base, you can control where each environment variable is used, either at build time or run time. 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 backend 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. App Hosting checks all of these boxes with automatic scaling with Cloud Run, scale to zero pricing,

and enterprise-grade secrets management. JULIA REID: 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 real world use cases. I have a customer building a modern e-commerce application

with Next.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?

THOMAS BOULDIN: 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 APIs 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 Auth. 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 server side 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 auth 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 cookie-based auth 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 floating point numbers representing the semantic meaning of text. To use this in your Next.js e-commerce app,

you first create a schema for your product's 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 Vertex 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 server side framework for interfacing with generative AI models

with GA support for node, js 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 RAG-based 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 cached 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, and 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 auto-initialize 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 apphosting.production.yaml

or apphosting.staging.yaml to override configurations from apphosting.yaml in 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 cherry pick 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 Memorystore 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 webhooks.

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 read only APIs.

JULIA REID: 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? THOMAS BOULDIN: OK.

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 apphosting.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 apphosting.emulator.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 Webhook

Secret in order to use the Stripe Webhook Emulator. My production application is still using Stripe Sandbox. So I don't actually need to overwrite that.

Now, in a previous run-through, 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 apphosting.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 webhook emulator and point it to my app. Memcache is already running as a Daemon.

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 byte 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 accuracy.

Let's jump to the Flows view and play with my Summarized Reviews Flow. I'm going to grab the product ID from that site

and pass it into the function. I'll leave Forced Refresh on and run a streaming response. Now, if I turn Forced 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 RAG-based 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. Now, while this is happening, pay attention

to this command line prompt. And you can see all of the Stripe webhooks 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 Auth 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 Auth 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, fetched reviews from Data Connect, called generate

for a RAG-based summary, and wrote to the cache, taking a total of 635 milliseconds. Meanwhile, a cached 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 Auto Init. Our networking layer includes Cloud CDN for faster response

times and VPC access to extend your app with internal services, like Cloud Memorystore, 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 a good state without rebuilding, which could create a different version if you statically render pages based on external data.

JULIA REID: 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. OK.

Now, I think we're ready to wrap up. Whether you're building with Angular, Next.js, Nuxt, 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 Init at App Hosting. If you have any feedback or feature requests, let us on UserVoice.

We'd love to hear from you. On behalf of Thomas and myself, thank you for watching. [MUSIC PLAYING]