This chapter covers Firebase, Google's mobile and web development platform, and its role in building modern apps. For the GCDL exam, Firebase appears in approximately 5-8% of questions, primarily in the 'Apps' domain (Objective 4.1). You will need to understand Firebase's core products—Authentication, Cloud Firestore, Realtime Database, Cloud Functions, Cloud Messaging, and Hosting—and how they integrate to accelerate app development. The exam tests your ability to recommend Firebase when requirements include real-time data sync, serverless backend, user authentication, and cross-platform support, and to differentiate Firebase from alternatives like custom backend services or other BaaS platforms.
Jump to a section
Imagine you want to open a restaurant but instead of building everything from scratch—kitchen, waitstaff, reservation system, loyalty program—you lease a fully equipped space from a provider. Firebase is like that provider for mobile and web apps. The provider offers a pre-built kitchen (Cloud Firestore for data storage), a waitstaff that takes orders and serves customers (Cloud Functions for serverless backend logic), a reservation system (Firebase Authentication for user sign-in), a menu board that updates in real-time (Realtime Database for live sync), and a loyalty card system (Cloud Messaging for push notifications). You, as the restaurant owner, focus on the menu and customer experience (your app's frontend and business logic), while the provider handles the infrastructure, scaling, and maintenance. Just as a full-service restaurant saves you from hiring architects, chefs, and waitstaff individually, Firebase saves you from managing servers, authentication systems, and database clusters. However, you are locked into the provider's kitchen layout and menu system—if you later want a custom grill, you may have to move out. Firebase's tight integration means your app's data, authentication, and messaging all work together seamlessly, but migrating away later requires significant rework.
What is Firebase and Why Does It Exist?
Firebase is a Backend-as-a-Service (BaaS) platform acquired by Google in 2014. It provides a suite of cloud-based tools and services that developers use to build, improve, and grow mobile and web applications without managing server infrastructure. Before Firebase, developers had to set up and maintain their own backend servers, databases, authentication systems, and APIs. Firebase abstracts all that away, offering pre-built, scalable services that integrate seamlessly. The core value proposition is speed of development: a developer can add authentication, a real-time database, and cloud functions to an app in minutes, not weeks.
How Firebase Works Internally
Firebase is not a single product but a collection of integrated services. The most important for the exam are:
Firebase Authentication: Provides backend services, easy-to-use SDKs, and ready-made UI libraries to authenticate users to your app. It supports authentication using passwords, phone numbers, popular federated identity providers like Google, Facebook, Twitter, and GitHub, and more. Under the hood, Firebase Authentication uses OAuth 2.0 and OpenID Connect protocols. When a user signs in, the Firebase SDK communicates with the authentication backend, which generates a JSON Web Token (JWT) containing user identity claims. This token is then used to authenticate subsequent requests to Firebase services or your own backend.
Cloud Firestore: A flexible, scalable NoSQL cloud database to store and sync data for client- and server-side development. It is the successor to the Realtime Database. Firestore stores data in documents (which are similar to JSON objects) organized into collections. Documents can contain subcollections. Firestore supports real-time listeners: when a client listens to a document or query, the SDK establishes a persistent WebSocket connection to the Firestore backend. Any change to the data is pushed to the client instantly. Firestore also provides offline persistence—data is cached locally on the device, and writes are queued when offline and synced when connectivity returns.
Realtime Database: The original Firebase database. It is a cloud-hosted NoSQL database that stores data as a single JSON tree and synchronizes changes in real-time to every connected client. Unlike Firestore, it does not support complex queries or subcollections. Data is structured as a JSON tree, and any change to a node triggers immediate updates to all clients observing that node. It uses a WebSocket-based connection for real-time sync. The Realtime Database is best suited for simple, low-latency use cases like chat apps or live cursors.
Cloud Functions for Firebase: A serverless framework that lets you run backend code in response to events triggered by Firebase features and HTTPS requests. Functions are written in Node.js (JavaScript/TypeScript) or Python and are executed in Google's managed environment. When an event occurs (e.g., a new user signs up, a document is written in Firestore, a file is uploaded to Cloud Storage), a corresponding function is invoked. The function runs in a container that is automatically scaled. You pay only for compute time while the function is executing. The default timeout for HTTP functions is 60 seconds, and for background functions it is 540 seconds (9 minutes). The maximum memory per function instance is 8 GB.
Firebase Cloud Messaging (FCM): A cross-platform messaging solution that lets you reliably deliver messages at no cost. FCM can send notification messages (displayed to the user) and data messages (processed by the app in the background). It uses Google's infrastructure to deliver messages to Android, iOS, and web clients. For Android, FCM uses the same underlying connection as Google Play Services. For iOS, it uses APNs (Apple Push Notification service) as the delivery layer. For web, it uses the Web Push API. FCM supports topic-based messaging (all clients subscribed to a topic receive the message) and device group messaging. The default message expiry is 28 days.
Firebase Hosting: Production-grade web content hosting for developers. With a single command, you can deploy web apps and static content to a global CDN (Content Delivery Network) backed by Google's global edge network. Hosting supports custom domains, SSL certificates automatically provisioned, and serverless functions via Cloud Functions. When you deploy, Firebase Hosting uploads your files to a Google Cloud Storage bucket and serves them from edge caches. The default cache-control header is set to 1 hour for static assets, but you can configure it.
Firebase Storage: Powered by Google Cloud Storage, it provides secure file uploads and downloads for Firebase apps. The Firebase SDKs handle network interruptions gracefully, and security is enforced via Firebase Security Rules. Files are stored in a Cloud Storage bucket, and access is controlled by rules that can be based on user authentication.
Key Components, Values, Defaults, and Timers
Firebase Authentication: Token expiry: ID tokens expire after 1 hour. Refresh tokens expire after 14 days if not used, but are automatically refreshed by the SDK. The default session length is 1 hour, but can be configured.
Cloud Firestore: Default write/read quotas: Free tier includes 50,000 reads, 20,000 writes, 20,000 deletes per day. Beyond that, pricing is per operation. Real-time listeners count as reads for each initial query and each document change. Offline persistence: enabled by default on Android and iOS; on web, it must be explicitly enabled.
Realtime Database: Default write/read quotas: Free tier includes 10 GB downloaded, 100 simultaneous connections, 1 GB stored. Pricing based on bandwidth and storage. Data is structured as a JSON tree; maximum depth is 32 levels.
Cloud Functions: Timeout: HTTP functions default 60s, max 540s (9 min). Background functions default 60s, max 540s. Memory: default 256 MB, max 8 GB. Concurrency: by default, each function instance handles one request at a time; you can set max instances per function (default 3000 for HTTP, 3000 for background).
FCM: Message expiry: default 28 days. Maximum payload size: 4 KB for notification messages, 2 KB for data messages. Topic subscription: a client can subscribe to up to 2,000 topics.
Firebase Hosting: Default cache-control: 1 hour for static files. Custom headers can be configured in firebase.json. SSL: automatically provisioned and managed via Let's Encrypt.
Configuration and Verification Commands
Firebase projects are managed via the Firebase CLI. Common commands:
# Initialize Firebase in a project directory
firebase init
# Deploy to Firebase Hosting
firebase deploy --only hosting
# Deploy Cloud Functions
firebase deploy --only functions
# Deploy Firestore security rules
firebase deploy --only firestore:rules
# View logs for Cloud Functions
firebase functions:log
# Emulate Firebase services locally
firebase emulators:startHow Firebase Interacts with Related Technologies
Firebase is built on top of Google Cloud Platform (GCP). Cloud Firestore and Realtime Database use Google's infrastructure for storage and replication. Cloud Functions runs on Cloud Run (serverless containers). Firebase Storage uses Cloud Storage buckets. Firebase Hosting uses Cloud CDN and Cloud Storage. Firebase Authentication integrates with Google Cloud Identity Platform. This tight integration means that as your app grows, you can seamlessly access other GCP services like BigQuery for analytics, Pub/Sub for event-driven messaging, and Cloud Tasks for asynchronous processing. However, Firebase is designed to be used as a standalone platform for most mobile and web apps, and the exam focuses on its ease of use and rapid development capabilities.
Create a Firebase Project
Go to the Firebase Console (console.firebase.google.com) and click 'Add project'. You can either create a new Google Cloud project or use an existing one. During creation, you can enable Google Analytics for your project (recommended for app analytics). After creation, you'll get a unique project ID and number. This project is the container for all Firebase services. In the console, you can then add apps (iOS, Android, Web, Unity) to the project, each with its own configuration object (google-services.json for Android, GoogleService-Info.plist for iOS, and a config object for web). This step is the foundation—without a project, no Firebase services can be used.
Integrate Firebase SDKs
For each platform, download the configuration file and add it to your app project. Then add the Firebase SDK dependencies. For Android, add google-services plugin and dependencies in build.gradle. For iOS, use CocoaPods or Swift Package Manager. For web, add script tags or import the npm package. After initialization, the SDK establishes a connection to the Firebase backend. The first SDK operation (e.g., calling FirebaseAuth.getInstance()) triggers a background initialization that loads configuration and establishes the necessary network connections. The SDKs are designed to work offline: they cache configuration and data locally, and queue writes for later sync.
Implement Authentication
In the Firebase Console, enable sign-in methods (e.g., Email/Password, Google, Facebook). Then, in your app, use the Firebase Authentication SDK to present sign-in UI or programmatically sign in. For example, using the email/password method: call createUserWithEmailAndPassword(email, password) for sign-up or signInWithEmailAndPassword(email, password) for sign-in. On success, the SDK returns a FirebaseUser object containing user details. The user's ID token (JWT) is automatically refreshed by the SDK. You can access the current user via FirebaseAuth.getInstance().getCurrentUser(). The exam expects you to know that Authentication is the entry point for securing other Firebase services.
Set Up Firestore Database
In the Firebase Console, create a Cloud Firestore database. Choose a location (e.g., nam5 for US multi-region). Then define security rules to control access. For example, allow read/write only if the user is authenticated. In your app, get a reference to Firestore: FirebaseFirestore db = FirebaseFirestore.getInstance();. To write data, use db.collection("users").add(userData) or db.collection("users").document(userId).set(userData). To read, use db.collection("users").get() for one-time read or addSnapshotListener() for real-time updates. Firestore automatically indexes fields for simple queries; for compound queries, you may need to create composite indexes in the console.
Add Cloud Functions
Initialize Cloud Functions in your project: firebase init functions. Write your function in the functions/index.js file. For example, a function that sends a welcome email when a user signs up: exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => { ... });. Deploy with firebase deploy --only functions. The function is triggered by the auth event. Under the hood, the Firebase backend publishes an event to Cloud Pub/Sub, which invokes the function. The function runs in a Node.js environment with access to other Firebase services via the Admin SDK. The exam tests that Cloud Functions enable serverless backend logic without managing servers.
Enterprise Scenario 1: Real-Time Collaboration App
A startup building a collaborative whiteboard app for remote teams uses Firebase as its primary backend. They use Cloud Firestore to store board data (shapes, text, images) as documents in a collection. Each board is a document, and changes are synced in real-time to all connected users via Firestore's snapshot listeners. Firebase Authentication handles user sign-in via Google and email/password. Cloud Functions are used to generate thumbnails of uploaded images (triggered by Cloud Storage uploads) and to send push notifications via FCM when a user is mentioned. The app scales to thousands of concurrent users without the team managing any servers. A common misconfiguration is failing to set proper security rules, leaving the database open to unauthorized reads. The team must write rules that allow read/write only to authenticated users who are members of the board. Performance consideration: Firestore's real-time listeners count as reads, so a board with 100 users each listening to the same document incurs 100 reads per document change, which can quickly exceed free tier quotas. The team mitigates this by using subcollections for fine-grained listening.
Enterprise Scenario 2: E-Commerce Mobile App
A retail company builds a mobile app for online shopping using Firebase. They use Firebase Authentication for user login, including phone number authentication for two-factor verification. Cloud Firestore stores product catalogs, user profiles, and order histories. Firebase Hosting serves the admin dashboard (a web app) with a custom domain. Cloud Functions handle order processing: when a user places an order, a function is triggered (via Firestore write) that validates the order, charges the customer via a third-party payment API, and updates inventory. FCM sends order confirmation and shipping updates to the user's device. The app uses offline persistence so users can browse products without internet. A challenge is that Firestore's offline persistence can lead to stale data if the user's local cache is not refreshed. The company configures TTL (time-to-live) for certain collections to force re-fetch. Another issue: Cloud Functions timeout for payment processing must be set appropriately (max 540s) to handle slow payment gateways. Misconfiguring security rules can expose customer data, so the team implements granular rules using custom claims.
Enterprise Scenario 3: Social Media Platform
A social media startup uses Firebase Realtime Database for real-time features like chat and live notifications, and Firestore for user profiles and posts (which don't need sub-millisecond updates). They use Firebase Authentication with multiple providers (Google, Facebook, Twitter). Cloud Functions moderate content by scanning images (via Cloud Vision API) and text for inappropriate content. FCM sends push notifications for new messages and friend requests. The platform serves millions of users. A common mistake is using Realtime Database for everything, which becomes unmanageable due to its JSON tree structure and lack of complex querying. The team learned to use Firestore for structured data and Realtime Database only for real-time features. They also encountered scaling issues with Realtime Database's 100 simultaneous connections limit on the free tier, forcing them to upgrade to a paid plan. Security rules became complex: they had to write rules that allow reading a user's posts only if the requester is a friend, which required denormalizing friend lists into the database.
What GCDL Tests on Firebase (Objective 4.1)
The GCDL exam focuses on high-level understanding of Firebase services and their use cases, not on detailed configuration commands. You should be able to:
Identify which Firebase service to use for a given requirement (e.g., real-time data sync → Realtime Database or Firestore; serverless backend → Cloud Functions; push notifications → FCM; user authentication → Firebase Authentication; static web hosting → Firebase Hosting; file storage → Cloud Storage).
Understand the difference between Firestore and Realtime Database: Firestore is newer, supports complex queries, scales better, and organizes data in documents/collections; Realtime Database is older, uses a JSON tree, and is simpler for low-latency real-time sync but lacks querying capabilities.
Know that Firebase Authentication supports multiple providers and integrates with other Firebase services for security.
Recognize that Cloud Functions are event-driven and can be triggered by Firebase events (auth, database, storage, etc.) and HTTPS requests.
Understand that Firebase Hosting provides global CDN, SSL, and custom domains.
Know that Firebase projects are Google Cloud projects, and that Firebase services can be accessed via GCP APIs.
Common Wrong Answers and Why Candidates Choose Them
Choosing Realtime Database over Firestore for a complex app with many relationships. Candidates often pick Realtime Database because they remember it as 'real-time', but Firestore is the recommended choice for most new apps due to its better querying and scaling. The exam tests this distinction.
Selecting Cloud Functions for long-running tasks. Candidates may think Cloud Functions can handle any backend logic, but they have a timeout (max 540s). For tasks that take longer, they should use Cloud Tasks or Cloud Run. The exam might present a scenario requiring a background job that runs for hours.
Assuming Firebase Hosting can serve dynamic content without Cloud Functions. Firebase Hosting is for static content; dynamic requests must be handled by Cloud Functions or another backend. Candidates might incorrectly think Hosting alone can process server-side logic.
Thinking Firebase Authentication is only for user sign-in, not for authorization. While Authentication provides identity, authorization is enforced through Security Rules and custom claims. The exam may ask how to control access to data based on user roles.
Specific Numbers and Terms That Appear on the Exam
Firestore vs. Realtime Database: 'document/collection' vs. 'JSON tree'
Cloud Functions timeout: '540 seconds' (9 minutes)
FCM: 'topic messaging' and 'device groups'
Firebase Hosting: 'global CDN', 'SSL certificate'
Firebase Authentication: 'OAuth 2.0', 'JWT'
Edge Cases and Exceptions
Offline persistence: Firestore and Realtime Database both support offline writes, but Realtime Database does not support offline queries beyond simple key lookups.
Security rules: Firestore rules use a different syntax than Realtime Database rules.
Multi-region: Firestore can be configured as multi-region for higher availability; Realtime Database is always single-region.
Emulator suite: Firebase provides local emulators for testing, but the exam does not require knowledge of emulator commands.
How to Eliminate Wrong Answers
When a question asks which Firebase service to use for a specific need, eliminate options that don't match the core functionality. For real-time sync, eliminate Cloud Functions and Hosting. For serverless compute, eliminate Firestore and Realtime Database. For file storage, eliminate Authentication and FCM. Also, consider the complexity: if the need is simple key-value sync, Realtime Database may be acceptable; for complex queries, Firestore is better. If the need is push notifications, FCM is the only choice.
Firebase is a Backend-as-a-Service (BaaS) platform that provides authentication, databases, serverless functions, hosting, and messaging for mobile and web apps.
Cloud Firestore is the recommended database for new apps due to its document/collection model, complex querying, and automatic scaling.
Realtime Database is suitable for simple, low-latency real-time sync but lacks querying capabilities and scales less well.
Cloud Functions are serverless, event-driven functions with a maximum timeout of 540 seconds (9 minutes).
Firebase Authentication supports multiple identity providers including Google, Facebook, and phone number, and uses OAuth 2.0/OpenID Connect.
Firebase Hosting serves static content over a global CDN with automatic SSL and custom domains.
FCM (Firebase Cloud Messaging) delivers push notifications to Android, iOS, and web with topic and device group messaging.
Firebase projects are Google Cloud projects; Firebase services can be accessed via GCP APIs and IAM.
Security Rules are used to control access to Firestore, Realtime Database, and Cloud Storage.
The Firebase CLI is used for deployment and local emulation of services.
These come up on the exam all the time. Here's how to tell them apart.
Firebase
Faster development: pre-built services for auth, database, storage, messaging.
Automatic scaling: no server management needed.
Built-in security rules for data access control.
Real-time data sync with WebSocket connections.
Tight integration across services (e.g., auth triggers Cloud Functions).
Custom Backend (e.g., on Compute Engine)
Full control over backend architecture and code.
No vendor lock-in; can use any database or language.
Potentially lower cost at very high scale (no per-operation fees).
Custom authentication flows and complex business logic without limitations.
Requires DevOps effort: server provisioning, patching, monitoring.
Cloud Firestore
Data model: documents and collections (hierarchical).
Supports complex queries: compound, range, sorting, and filtering.
Automatic multi-region replication for high availability.
Better scaling: designed for large datasets and many concurrent connections.
Offline persistence with conflict resolution.
Realtime Database
Data model: single JSON tree (no subcollections).
Shallow queries only; no compound or range queries.
Single-region only (unless using third-party replication).
Limited scaling: max 100 simultaneous connections on free tier, 200,000 on paid.
Simpler real-time sync with lower latency for small datasets.
Mistake
Firebase Realtime Database is better than Cloud Firestore for all real-time apps.
Correct
Cloud Firestore is the recommended database for most new apps. It offers more powerful querying, better scaling, and a more intuitive data model (documents and collections). Realtime Database is simpler but limited to JSON tree structures and shallow queries. The exam expects you to recommend Firestore unless the app requires extremely low latency and simple data structures.
Mistake
Cloud Functions can run indefinitely for long-running tasks.
Correct
Cloud Functions have a maximum timeout of 540 seconds (9 minutes) for background functions and 60 seconds for HTTP functions (configurable up to 540s). For tasks that exceed this, you should use Cloud Tasks, Cloud Run, or Compute Engine. The exam tests this limit.
Mistake
Firebase Hosting can serve dynamic content without additional services.
Correct
Firebase Hosting serves only static content (HTML, CSS, JS, images). Dynamic requests must be handled by Cloud Functions or Cloud Run, which can be integrated via rewrites in firebase.json. The exam expects you to know that Hosting is for static assets.
Mistake
Firebase Authentication only supports email/password login.
Correct
Firebase Authentication supports multiple providers: Google, Facebook, Twitter, GitHub, Microsoft, Yahoo, phone number, and more. It also supports anonymous authentication and custom authentication systems. The exam tests that you know Authentication is multi-provider.
Mistake
Firebase and Google Cloud are separate, unrelated platforms.
Correct
Firebase is built on Google Cloud Platform. Firebase projects are Google Cloud projects. Firebase services (like Firestore, Cloud Functions, Storage) use underlying GCP services. You can access Firebase resources via GCP APIs and IAM. The exam expects you to understand this integration.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud Firestore is the newer, more feature-rich database. It organizes data in documents and collections, supports complex queries (compound, range, sorting), automatic multi-region replication, and better scaling. Realtime Database stores data as a single JSON tree, supports only shallow queries, and is limited to single-region. For most new apps, Firestore is recommended. Realtime Database is simpler and may be suitable for low-latency, simple data structures like chat messages. The exam tests this distinction.
Firebase Authentication provides backend services and SDKs to authenticate users. It supports multiple identity providers (email/password, Google, Facebook, phone, etc.) via OAuth 2.0 and OpenID Connect. When a user signs in, the SDK communicates with the Firebase Auth backend, which returns a JSON Web Token (JWT) as an ID token. This token is used to authorize access to other Firebase services (e.g., Firestore, Realtime Database) via Security Rules. The SDK automatically refreshes the token before expiry (1 hour).
Yes. Firebase services can be used alongside a custom backend. For example, you can use Firebase Authentication for user sign-in while running your own server for business logic. The Firebase Admin SDK allows your backend to verify Firebase tokens and interact with Firebase services. You can also use Cloud Functions as a serverless backend that integrates with Firebase. The exam expects you to know that Firebase is flexible and can complement existing infrastructure.
Security Rules are declarative rules that control read and write access to Firestore, Realtime Database, and Cloud Storage. They are written in a JSON-like syntax and are evaluated on the server. For example, you can allow read/write only if the user is authenticated, or only if the user's UID matches the document's owner field. Rules are defined in the Firebase Console or in firebase.rules files. They are essential for securing data and are a common exam topic.
Firebase Hosting serves static content (HTML, CSS, JS, images) from a global CDN backed by Google's edge network. You deploy using the Firebase CLI. Hosting automatically provisions an SSL certificate via Let's Encrypt and supports custom domains. Dynamic content can be handled via Cloud Functions or Cloud Run using rewrites in the firebase.json configuration. The default cache-control is 1 hour for static assets. Exam tip: remember that Hosting is for static content only.
The maximum timeout for a Cloud Function is 540 seconds (9 minutes) for background functions (e.g., triggered by Firestore events) and 60 seconds for HTTP functions, though HTTP functions can be configured up to 540 seconds as well. If your task takes longer, you should use Cloud Tasks, Cloud Run, or Compute Engine. The exam tests this value.
Yes, Firebase provides a JavaScript SDK for web apps. You can add Firebase to a web app via npm or script tags. All core Firebase services (Authentication, Firestore, Realtime Database, Storage, Cloud Functions, Hosting, FCM) are available for web. Firebase Hosting is specifically designed for deploying web apps. The exam covers Firebase for both mobile and web.
You've just covered Firebase for Mobile and Web Apps — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?