Project Overview & Why a Backend-as-a-Service

Food Tracker (React + Firebase)

Chapter 1 · Project Overview & Why a Backend-as-a-Service

This is one of four courses building the exact same app in four genuinely different architectures — Food Tracker (FastAPI), Food Tracker (Django), and Food Tracker (React + Express) are its siblings. Every one of them scans a barcode, tracks a use-by date, and alerts you before something goes to waste. What differs, chapter by chapter, is where the backend actually lives — and this course's own answer is the most unusual of the four: nowhere you wrote yourself.

What the App Actually Does

Before any architecture talk, the shared spec every course in the quartet is building toward:

Scan a barcode with a phone or webcam camera, look it up against Open Food Facts (free, open, no API key) to fetch the product's name and details automatically.
Record a use-by date for the item, and see it flagged once it's expiring soon.
Keep a full history of every item ever added — some still active with a real expiry date, some already marked used with no expiry date at all — searchable in real time as you type, so re-adding something you've bought before is fast.
Look up recipes via TheMealDB (also free, no key) that use ingredients close to expiring.

A weekly meal planner is explicitly out of scope for all four courses — named future work, not something any of them will build.

What Firebase Actually Provides

"Firebase" isn't one thing — it's a bundle of managed services, and this course leans on four of them directly:

Firestore — a NoSQL, document-based database. Chapter 2 goes deep on what that means for this app's own data model, in direct contrast to the SQL schemas the other three courses use.
Cloud Functions — small, serverless backend functions, triggered by an HTTP call or a database event. Chapters 3 and 10 use these for exactly the two places this app still needs a genuine server: proxying the Open Food Facts and TheMealDB lookups.
Firestore Security Rules — declarative rules controlling who can read or write what, enforced by Firebase itself rather than by code you run. Chapter 6 covers these in depth, once the app starts writing directly to the database from the browser.
Firebase Authentication — managed sign-in and user accounts, covered in Chapter 11 as a natural extra this course can afford that its siblings reasonably skip.
Firebase Hosting — static hosting for the finished React build, covered in Chapter 12.

The Architecture Contrast, Precisely

Course	Backend	Where business logic lives
Food Tracker (FastAPI)	A FastAPI process you write, run, and deploy	Python code you author, running on a server you manage
Food Tracker (Django)	A Django process you write, run, and deploy	Python code you author, running on a server you manage
Food Tracker (React + Express)	A Node/Express process you write, run, and deploy	JavaScript code you author, running on a server you manage
Food Tracker (React + Firebase)	No server process you write or deploy	Mostly Security Rules (configuration, not code) plus a small number of Cloud Functions for the few things that genuinely need one

The one-sentence version of this whole course

In the other three Food Tracker courses, all business logic and validation lives in code you write and run yourself. In this one, most of it lives in configuration — Security Rules — and managed infrastructure, with your own code shrunk down to the handful of places that genuinely need a trusted secret or heavier compute than the client should do alone.

Setting Up a Firebase Project

Create a project at the Firebase console, enable Firestore in production mode (not test mode — test mode allows unrestricted reads and writes, which Chapter 6 will replace with real rules), then bring the Firebase SDK into the React app:

npm install firebase

// firebase.js
import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

const firebaseConfig = {
  apiKey: "AIzaSy...",
  authDomain: "food-tracker-xxxx.firebaseapp.com",
  projectId: "food-tracker-xxxx",
};

const app = initializeApp(firebaseConfig);
export const db = getFirestore(app);

That config object is not a secret — really

Coming from a "never expose your API key" mindset, pasting `apiKey` directly into frontend source code looks alarming. It isn't: Firebase's client-side config values identify which Firebase project a request is talking to — they don't grant access to anything by themselves. Actual access control is enforced entirely by Security Rules (Chapter 6), evaluated on Firebase's own servers for every single read and write, regardless of what config values the client presents. A genuine secret — an API key for a third-party service that must never reach the browser — is exactly why Cloud Functions exist at all, and exactly what Chapters 3 and 10 use them for.

Develop against emulators, not the live project

npm install -g firebase-tools, then firebase login and firebase init emulators sets up local Firestore and Cloud Functions emulators. Building against these instead of the real cloud project from day one avoids racking up usage, avoids polluting real data with test writes, and makes Chapter 6's security-rules work far faster to iterate on.

Where This Course Is Headed

Data modeling in Firestore, barcode lookup via a Cloud Function, the camera-scanning React component (shared almost verbatim with Food Tracker (React + Express)), direct client writes to Firestore, Security Rules as the real gatekeeper, expiry alerts, item history with the honest limits of Firestore's own search capability, marking items used, recipe lookup, Firebase Authentication, deployment, and a capstone tying every chapter into one complete, working app.

Hands-On Exercises

Exercise 1

In one sentence, state the fundamental architectural difference between this course and its three siblings. Then explain, using this chapter's own comparison table, what "where business logic lives" actually means for each of the four.

📄 View solution

Exercise 2

Explain why Firebase's client-side config object (apiKey, projectId, etc.) is safe to include directly in frontend source code, when a traditional server API key is not. What actually enforces access control instead?

📄 View solution

Exercise 3

Name the four Firebase products this chapter previews, and match each one to the later chapter that covers it in depth.

📄 View solution

Chapter 1 Quick Reference

The shared app — barcode scan (Open Food Facts) → expiry tracking → alerts → searchable history → recipe lookup (TheMealDB); no meal planner
Firestore — NoSQL document database (Ch.2)
Cloud Functions — serverless functions for the two places a real secret is needed (Ch.3, Ch.10)
Security Rules — the actual gatekeeper once the client writes directly to the database (Ch.6)
Firebase Authentication — real user accounts, a near-free extra (Ch.11)
This course's own throughline: business logic lives mostly in configuration and managed infrastructure, not in a server process you write and run
Next chapter: Data Modeling in Firestore