Theory
Firebase on both ends
Firebase shows up on both sides of FestConnect, but in two different forms, and understanding the difference is the key security idea of this lesson.
In the Angular front end you use the client Firebase SDK for user login and data. In the Express backend you use the Firebase Admin SDK for privileged, trusted work. And Firebase Hosting serves the finished app. This lesson connects these pieces and, crucially, explains why the client SDK and the Admin SDK are deliberately different in power.
Theory
Client SDK vs Admin SDK
The client SDK runs in the browser (Angular). It uses the app's public configuration and acts as the logged-in user, so its access is limited by Firebase security rules. It handles signing in and reading or writing the data that user is allowed to touch.
The Admin SDK runs on the server (Express) with privileged credentials (a service account key). It can do trusted things the client cannot, verify ID tokens, and read or write data bypassing client security rules. Because it is so powerful, its credentials must be kept secret on the server, never shipped to the browser. Client SDK: limited, public, per-user. Admin SDK: privileged, secret, server-only.
Practical
Angular: initialise the client Firebase SDK
import { initializeApp } from 'firebase/app';
// Public config (safe to ship to the browser); access is limited by
// Firebase security rules and the logged-in user.
const firebaseConfig = {
apiKey: '...', authDomain: 'festconnect.firebaseapp.com',
projectId: 'festconnect', /* ... */
};
export const app = initializeApp(firebaseConfig);
// From here, getAuth(app) for login and getFirestore(app) for data.Practical
Express: initialise the privileged Admin SDK
const admin = require('firebase-admin');
// The service account key is SECRET, kept on the server, never in the browser
admin.initializeApp({
credential: admin.credential.cert(require('./serviceAccountKey.json')),
});
// Now the server can verify tokens and do trusted work:
// await admin.auth().verifyIdToken(token);
// (keep serviceAccountKey.json out of version control, e.g. via .env / secrets)This example runs in Gri-Learn on the web, where you can edit it and see the output.
Formula
Deploying with Firebase Hosting
To put FestConnect online, you build the Angular app (ng build) and deploy the output with Firebase Hosting: firebase init hosting (point it at the build output), then firebase deploy. Firebase serves your static front end over a global CDN with HTTPS, fast and secure by default.
So the front end is hosted by Firebase, talks to Firebase Auth and Firestore via the client SDK, and (for trusted operations) to your Express API which uses the Admin SDK. Firebase can provide most of the backend, with Express adding your custom server logic. A complete, deployable full-stack app.
Quiz
Why must the Firebase Admin SDK's service account credentials stay on the server and never be shipped to the Angular browser app?
- Because the browser cannot run JavaScript
- Because the Admin SDK is privileged (it bypasses client security rules and does trusted operations), so exposing its credentials would let anyone perform those privileged actions
- Because the Admin SDK is slower in the browser
- There is no reason; it is fine to ship them
Show the answer
Because the Admin SDK is privileged (it bypasses client security rules and does trusted operations), so exposing its credentials would let anyone perform those privileged actions
The Admin SDK runs with privileged service-account credentials that bypass client security rules and can perform trusted operations (verifying tokens, unrestricted data access). If those credentials were shipped to the browser, anyone could extract them and gain that privileged power over your project, a severe security breach. So they must remain secret on the server. Option A is false: browsers run JavaScript fine; that is not the issue. Option C invents a performance reason; the concern is security, not speed. Option D is dangerously wrong: shipping admin credentials to clients is exactly what you must never do. Client SDK is safe to ship (public, limited); Admin SDK credentials are secret and server-only.
Think first
Why have two SDKs at all instead of one that does everything?
Why does Firebase deliberately split into a limited client SDK and a privileged Admin SDK? Then tap.
Show the answer
Because the browser is an UNTRUSTED environment and the server is a TRUSTED one, and giving each the right amount of power is the foundation of secure design. Anything shipped to the browser, including code and configuration, can be read and tampered with by anyone using the app, so whatever the client SDK can do, a malicious user can attempt too. That is why the client SDK is deliberately LIMITED: it acts as the logged-in user and is constrained by Firebase security rules, so even though its config is public, a user can only ever do what those rules permit for their own account, they cannot read others' private data or perform admin actions. The Admin SDK, by contrast, is meant only for the server, a place you control and attackers cannot inspect, so it is safe to give it PRIVILEGED, unrestricted power to verify tokens, enforce custom logic, and manage data beyond any single user's rights. Splitting into two SDKs lets Firebase match capability to trust: broad but public and limited for the client, powerful but secret and server-only for the admin. If instead there were one all-powerful SDK used everywhere, you would either have to ship admin power to the browser (a catastrophic security hole) or cripple the server. The two-SDK design is a clean expression of the principle running through this whole unit: never trust the client, do privileged work on the server. Power where it is safe, limits where it is exposed.
Summary
Key takeaways
- Firebase plugs into both ends of the stack, in two different forms.
- The client Firebase SDK runs in Angular with public config, acts as the logged-in user, and is limited by security rules (login, data).
- The Firebase Admin SDK runs on the Express server with privileged, secret service-account credentials for trusted work (verifying tokens, unrestricted access).
- Admin credentials must stay on the server and never be shipped to the browser, or anyone could gain that privileged power.
- Firebase Hosting serves the built Angular app (ng build, then firebase deploy) over a global HTTPS CDN.
- Two SDKs exist because the browser is untrusted (limited client SDK) and the server is trusted (privileged Admin SDK).
- Memory hook: client SDK public and limited, Admin SDK secret and privileged, host the front end on Firebase Hosting.