DEV Community: Azhar Alvi

Phase 4 [Part 2] : The Deviation

Azhar Alvi — Sun, 02 Aug 2026 15:05:28 +0000

Kill the 30-minute dead-end where an expired token traps you on a broken screen, break one bloated component into smaller ones that each own their job, and give the login and app shell their first real coat of paint — the two debts I flagged at the end of Part 1, plus the refactor that made fixing them possible.

At the close of Part 1, my app finally had a face: I could log in through a real form and do full CRUD without ever opening /docs. Genuinely a milestone. But I ended that write-up with two honest confessions taped to the fridge. One: the login silently dies after 30 minutes — my JWTs expire, and when they do, the app just shows a confusing error and strands you, still pretending you're logged in. Two: it looked like a 1998 government form. A raw list, no styling, no polish.

I said I'd deal with both in "Phase 5." I changed my mind again.

A second confession: I pulled two Phase-5 jobs forward [and picked up a third I didn't plan]

Building a dashboard on top of a frontend that (a) traps users on a dead session, (b) crams everything into two god-components, and (c) is visually unusable felt like laying a nice floor over a cracked foundation. So before any new features, I spent a session paying rent on the foundation.

And here's the honest part: only one of these three jobs was on my list. The expired-token fix, yes — I'd flagged it. But chasing that bug is what dragged the props refactor in behind it, because the fix literally couldn't be written cleanly until I'd split my components up. One debt exposed another. That happens a lot, I'm learning.

Let's call it PHASE 4, PART 2 — Paying the Rent:

Reproduce the expired-token dead-end on purpose [without waiting 30 minutes]
Detect a 401 on any request and force a clean re-login
Learn props for real — by passing a function down so a child can trigger the parent's logout
Split App and ExpenseList into <LoginForm> and <AddExpenseForm>
Install Tailwind v4 [which is nothing like the tutorials you'll find]
Style the login into a centered card and the app into a dashboard shell
Make an honest call about a lint warning instead of cargo-culting a "fix"

Debt #1: the 30-minute dead-end [expired-token hardening]

Here's the flaw, stated plainly. My login issues a JWT with a 30-minute self-destruct baked in [the exp claim — Phase 3 me set that on purpose]. After 30 minutes the token is dead, and my FastAPI backend will reject any authenticated request — list, add, edit, delete — with a 401 Unauthorized. That's not a bug; that's the security feature working exactly as designed.

The bug was my reaction to it. My fetchExpenses caught any bad response as a generic "Could not load expenses," and my mutation handlers just console.error-ed the status. Meanwhile App still had a truthy token in state, so it kept rendering the logged-in view. The token was dead, but the app cheerfully pretended I was alive — an error message, a Logout button, and no automatic way out. A dead-end.

First move, and this is the adversarial habit surviving without the GAN framing: I reproduced the failure on purpose instead of waiting half an hour. DevTools → Application → Local Storage → double-click the token value → jam a few junk characters onto the end → hit an endpoint. An invalid token gets the exact same 401 an expired one would. Instant, repeatable bug. Watching it fail on demand is what made the fix obvious.

Then I hit the wall that turned this into a bigger job than expected:

The logout logic lived in the wrong place to fix this. My handleLogout [localStorage.removeItem('token') + setToken(null)] sits in App, the parent. But the 401 happens inside ExpenseList, the child. A child component cannot reach up and grab its parent's functions on its own. So how does the child tell the parent "the session is dead, log us out"? That question is what forced me to finally learn props — see the next section. The short version of the answer: the parent hands the child a function to call.

With that wired (details below), the fix inside each authed request was tiny and identical — check for 401 first, and if you see it, bail:

if (response.status === 401) {
  onAuthError();   // a function App passed down; it runs handleLogout
  return;
}

Gotcha #9 — a 401 is a subset of "not ok," so you have to catch it before your generic error branch. My old code did if (!response.ok) throw .... If I'd let that run first, every expired token would just show "Could not load expenses" and never log me out. By checking response.status === 401 first and return-ing, I short-circuit: onAuthError() flips token to null up in App, App stops rendering ExpenseList, and the login screen takes over. Order matters. Specific case before general case.

I dropped that same three-line guard into all four authed calls — fetchExpenses, handleAdd, handleDelete, handleUpdate — and while I was crawling through handleDelete, I found a landmine:

Gotcha #10 — a one-letter case typo that "works" only by luck. My delete URL read http://Localhost:8000 — capital L. It had been working the whole time because Windows treats hostnames case-insensitively, so Localhost resolves fine on my machine. The moment I deploy the backend to a Linux box [Phase 9], that could bite. Fixed it to lowercase localhost now, while I was in the neighborhood. Lesson: "it works on my machine" and "it's correct" are not the same sentence.

The payoff: I re-ran my sabotage — logged in, corrupted the token, triggered a request — and instead of the stuck error screen, the app bounced me straight back to the login form. Tested it from a reload and from the add button, to prove the guard fires from more than one place. The session can no longer lie to me.

The cleanup I didn't plan on: props [the refactor]

Remember the wall above — the child couldn't reach the parent's logout. The clean answer to that is the single most important React concept I'd been avoiding: props.

Props are how a parent hands things down to a child — data, config, or [the part that unlocks everything] functions. And the mirror image is the pattern that fixed my bug: a child reports an event up by calling a function its parent passed down. That's it. Data flows down; events flow up as function calls. My onAuthError was my very first one — App handed ExpenseList its handleLogout, renamed onAuthError for clarity, and the child calls it when it smells a dead session.

// In App: hand the function down
<ExpenseList onAuthError={handleLogout} />

// In ExpenseList: receive it
function ExpenseList({ onAuthError }) {

That { onAuthError } in the function signature stopped me for a second, so I'll pin down what it is:

{ } in a component's arguments is object destructuring — the cousin of the [ ] I already knew from useState. React always calls my component with one argument: a single object holding all its props. { onAuthError } reaches into that object and pulls out the onAuthError key by name. Contrast: useState gives me const [value, setter] — array destructuring, which unpacks by position [that's why order matters there]. Objects unpack by name, so the name inside the braces must exactly match the prop I passed. A typo like { onAuthErr } just silently hands me undefined.

Once I understood props, the mess I'd been living in became obvious: my login form was welded inside App, and my add-expense form was welded inside ExpenseList. Two components doing three jobs each. So I split them out, and I picked a deliberate design rule for both:

Each form owns its own state and does its own API call, then reports the result up through a callback prop. The parent stays thin and owns only what's genuinely shared. App doesn't care about my email or password keystrokes — it only cares "did we get a token?" So LoginForm keeps its own email/password state, does the login fetch itself, and calls onLoggedIn(token) on success. This is colocation: keep state as close as possible to where it's used, and lift up only the thing that's actually shared [the token].

function LoginForm({ onLoggedIn }) {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  async function handleSubmit(event) {
    event.preventDefault();
    const formBody = new URLSearchParams();
    formBody.append("username", email);
    formBody.append("password", password);

    const response = await fetch("http://localhost:8000/auth/login", {
      method: "POST",
      headers: { "Content-Type": "application/x-www-form-urlencoded" },
      body: formBody,
    });

    if (response.ok) {
      const data = await response.json();
      onLoggedIn(data.access_token);   // report success UP to App
    } else {
      console.log("Login Failed:", response.status);
    }
  }
  // ...the form JSX
}

App shed all the login state and shrank to a coordinator — it now owns only the token plus two tiny handlers:

function handleLoginSuccess(newToken) {
  localStorage.setItem("token", newToken);   // the side-effect stays with the owner of the token
  setToken(newToken);
}
function handleLogout() {
  localStorage.removeItem("token");
  setToken(null);
}

<AddExpenseForm> came out the same way, except it needs two callbacks: onAdded [it succeeded — parent, please re-fetch the list] and onAuthError [the 401 guard]. And that surfaced a nice, normal wrinkle:

Prop-forwarding is fine and expected. ExpenseList receives onAuthError from App, and then passes it one level deeper to AddExpenseForm. A prop can be handed down through multiple layers. <AddExpenseForm onAdded={fetchExpenses} onAuthError={onAuthError} /> — notice onAdded={fetchExpenses} is me passing ExpenseList's own re-fetch function down so the child can trigger a refresh after a successful add. Same function, reused through a prop.

Two more real things fell out of the refactor:

Gotcha #11 — moving JSX into a child leaves leftovers in the parent. The instant I extracted <LoginForm>, my login screen showed the title twice. Cause: I'd put the <h1>Smart Expense Manager</h1> inside LoginForm, but App was still rendering its own old heading right above it. This is the exact same lesson as the stray-render leak from Part 1 — when you restructure, hunt the leftovers. The fix doubled as a design decision: the app title is shell UI, so it belongs in App, exactly once. LoginForm renders only the form.

Gotcha #12 — the tempting lint "fix" is an infinite-loop trap. ESLint started nagging: "React Hook useEffect has a missing dependency: 'fetchExpenses'." The obvious move is to obey it and write }, [fetchExpenses]). Don't. fetchExpenses is a plain function, so React creates a brand-new copy of it every render. Put it in the dependency array and the effect thinks its dependency changed on every render → it re-fetches → setState re-renders → new function copy → fetches again → infinite loop. My empty [] is actually the behavior I want [run once on mount]. So I made a real decision instead of cargo-culting: I left the warning alone. It's a warning, not an error, and the code is correct. I didn't even add an eslint-disable comment — that would just be decorating a non-problem. [The genuinely-correct fix is wrapping the function inuseCallbackso its identity is stable — but that cascades into memoizing the callbacks I pass down too, which is more machinery than a beginner project needs right now. useCallback = "know this exists."]

The whole app behaves identically after all this — same login, same CRUD, same 401 bounce. But App and ExpenseList are now thin coordinators, and each form is a small thing that owns its one job. That's the entire point of the refactor: no new features, just a codebase I can actually keep building on.

Debt #2: it looked like a 1998 government form [Tailwind]

Time to make it not-ugly. I chose Tailwind CSS [utility-first styling] and a modern SaaS-dashboard look — soft-gray canvas, white cards with subtle shadows, a top header bar. Partly because it's everywhere in industry, partly because that card-and-shell layout is a direct warm-up for the Phase 5 dashboard.

First lesson before I typed a single class:

Gotcha #13 — Tailwind v4 threw out the setup every tutorial still teaches. Search "install Tailwind" and you'll get v3 instructions: a tailwind.config.js, a content: [...] array, @tailwind base/components/utilities directives, PostCSS wiring. In v4, all of that is gone. It's now a Vite plugin plus a single line of CSS. I actually verified the current steps against today's docs instead of trusting my memory or an old blog — which is a habit I want to keep for fast-moving tools, because copying stale setup is a guaranteed hour lost.

The entire v4 setup, for a Vite + React app:

npm install tailwindcss @tailwindcss/vite

// vite.config.js — ADD the plugin, keep react()
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [react(), tailwindcss()],
})

/* src/index.css — this ONE line replaces all the old @tailwind directives */
@import "tailwindcss";

A restart of the dev server later [config changes don't hot-reload — one to remember], I dropped className="text-3xl font-bold text-blue-600" on my title, watched it go big and blue, and knew the pipe was live. Note it's className, not class — the same JSX rule that bit me back in Part 1, now paying dividends because every Tailwind style rides on className.

The mental model that made Tailwind click: you don't write CSS rules in a separate file. You compose a look out of tiny, single-purpose utility classes right on the element — p-8 is padding, rounded-xl is corners, shadow-md is a shadow, bg-white is the background. Honest reaction: the className strings get long and repetitive, and my two login inputs share an identical one. That felt wrong at first, but it's genuinely idiomatic Tailwind. [Later I can collapse a repeated set with@applyin CSS, or extract a tiny<Input>component. Know this exists; not now.]

Here's the login screen — a centered white card floating on a gray page:

// App's logged-out branch
<div className="min-h-screen bg-slate-100 flex items-center justify-center">
  <div className="w-full max-w-sm bg-white rounded-xl shadow-md p-8 flex flex-col gap-6">
    <h1 className="text-2xl font-bold text-slate-800 text-center">Smart Expense Manager</h1>
    <LoginForm onLoggedIn={handleLoginSuccess} />
  </div>
</div>

The handful of utilities I'll actually reuse forever:

flex items-center justify-center — the centering combo. items-center centers vertically, justify-center horizontally. Wrap it in min-h-screen so there's a full viewport to center within.
flex flex-col gap-* — stack children in a column with even spacing between them, no margins to hand-tune.
focus:ring-2 / hover:bg-blue-700 — the focus: and hover: prefixes apply a style only in that state. It's Tailwind's answer to CSS pseudo-classes, and it's genuinely elegant — my inputs get a blue focus ring, my button darkens on hover, all inline.

Then the logged-in shell — a real SaaS layout with a header bar and a centered content column:

<div className="min-h-screen bg-slate-100">
  <header className="bg-white shadow-sm">
    <div className="max-w-3xl mx-auto px-6 py-4 flex items-center justify-between">
      <h1 className="text-xl font-bold text-slate-800">Smart Expense Manager</h1>
      <button onClick={handleLogout} className="text-sm text-slate-600 border border-slate-300 rounded-md px-3 py-1.5 hover:bg-slate-50 transition-colors">
        Logout
      </button>
    </div>
  </header>
  <main className="max-w-3xl mx-auto px-6 py-8">
    <ExpenseList onAuthError={handleLogout} />
  </main>
</div>

Two things worth banking here:

<header> and <main> instead of <div>s. These are semantic HTML — they render identically but tell browsers and screen readers what each region is. A free accessibility and clarity win; a small habit that separates "works" from "professional."
max-w-3xl mx-auto is the centered-column pattern. max-w-3xl caps the width so content isn't a painfully wide ribbon on a big monitor; mx-auto sets left/right margins to auto, which centers the block. I used the same max-w-3xl mx-auto px-6 on both the header's inner div and <main>, which is what keeps the logo and the content aligned down the page. justify-between in the header shoves the title hard-left and Logout hard-right.

And one small stumble that taught the right instinct:

Gotcha #14 — reach for gap on the parent, not a margin on each child. My title and the email box were jammed together with no space. My first instinct was to slap a margin-bottom on the heading. The cleaner fix — and the more Tailwind-idiomatic one — was to make the card a flex flex-col gap-6 container, so the gap spaces every child uniformly [title → form] with one declaration on the parent. Set the rhythm once, up top, instead of hand-tuning margins on each element and fighting margin quirks.

Honest status: this is the pass I've started, not finished. The login card and the whole app shell are dressed and look legitimately decent. What's not done yet: the expense-list itself is still raw inside that nice shell — the list needs to become a card, the add-expense form needs the same input/button styling as login, and each row needs tidy edit/delete buttons and clean loading/empty/error states. That's the frontier, and it flows directly into Phase 5.

The shape of every React conversation [the model that tied it together]

If Part 1's big mental model was "the Save button doesn't save — it asks the backend to," Part 2's is smaller but just as clarifying:

Data flows down, events flow up, and only a state change repaints the screen.

A parent passes data or functions down to a child as props.
When something happens in the child [login succeeded, a 401 came back, an expense was added], the child calls a function the parent gave it — that's the event flowing back up.
That function, running in the parent, changes state [setToken(...)]. And state changing is the only thing that makes React re-render and swap the screen.

Every single thing I built this session is that loop. LoginForm → onLoggedIn(token) → setToken → the UI flips to logged-in. ExpenseList → onAuthError() → setToken(null) → the UI flips back to login. AddExpenseForm → onAdded() → re-fetch → the list re-renders. Once I saw the one shape, the whole component tree stopped being mysterious.

Stuff I want to remember [the honest takeaways]

A JWT expiring is the security feature working, not a bug — but not handling the resulting 401 is the bug. Detect it and force a clean re-login.
Reproduce a time-based bug on purpose — corrupt the token in DevTools instead of waiting 30 minutes. An invalid token gives the same 401 as an expired one.
Check the specific status [401] before the generic !response.ok branch, or the general case masks the special one. Specific before general.
Props are how a parent passes data — and functions — down; a child reports events up by calling a function the parent gave it. Data down, events up.
{ prop } in a component signature is object destructuring [by name]; useState's [value, setter] is array destructuring [by position]. Same idea, different brackets — and the prop name must match exactly.
Colocate state: each form owns its own state and its own API call; the parent stays thin and owns only what's shared [the token]. Lift up only the shared thing.
Prop-forwarding is normal — a prop can be handed down through several layers [App → ExpenseList → AddExpenseForm].
When you restructure, hunt the leftovers — moving JSX into a child left a duplicated <h1> behind in the parent. [Same lesson as Part 1's stray render. It keeps coming back.]
Don't cargo-cult a lint "fix." Obeying the exhaustive-deps warning naively [[fetchExpenses]] creates an infinite fetch loop, because the function is recreated every render. The empty [] was correct. A warning is not an error. [Real fix = useCallback; deferred.]
Tailwind v4 is nothing like the v3 tutorials — no config file, no content array, no @tailwind directives. Just the @tailwindcss/vite plugin + @import "tailwindcss";. Verify current docs for fast-moving tools.
Tailwind is utility-first: compose a look from tiny classes on className [still not class]. Long, repeated class strings are normal.
flex items-center justify-center centers; flex flex-col gap-* spaces stacked children [set spacing on the parent, not margins on each child]; focus:/hover: prefixes are Tailwind's pseudo-classes; max-w-* mx-auto is the centered column.
Use semantic <header>/<main> instead of <div> soup — free clarity and accessibility.
The one React loop: data down (props) → event up (callback) → setState → re-render. Everything I built is that shape.
Commit at every green checkpoint, subject + why. I committed after the 401 fix, after each extraction, and after the Tailwind install — small and often.

Next up: Phase 5, for real this time. The face now has a pulse [the session no longer dead-ends], its internals are organized [small components that each own their job], and it's wearing its first real clothes [a login card and a dashboard shell]. What's left is to finish dressing the expense list, and then give the app some actual expression: a dashboard with spending insights — totals, spend-by-category, month-over-month — turning "it works and it's tidy" into "I'd genuinely use this." The foundation's finally solid enough to build something interesting on top of. See you there.

PHASE 4 — The Face

Azhar Alvi — Sat, 01 Aug 2026 09:29:14 +0000

Scaffold a React app, log in through a real form, and do full CRUD without ever opening /docs again — then close the three gaps nobody builds: loading, empty, and error.

So by the end of Phase 3 my app had a memory [a database], a mouth [HTTP endpoints], and a lock on the door [auth]. It knew who you were and refused to show you anyone else's expenses. Genuinely satisfying. There was just one small, embarrassing detail: the only human who could actually use it was me, poking at /docs. My "app" was a Swagger page and a lot of faith. No screen, no login box, nothing a normal person could look at. It had everything except a face.

Phase 4 gives it one.

A confession before we start: I changed the plan

If you read the end of my Phase 3 write-up, I promised Phase 4 would be filtering, sorting, and pagination — making the backend list usable at scale. I changed my mind. I went with frontend.

My reasoning, honestly: I've been living in Python for four phases and I've never touched React. Building the UI now forces me to re-meet my own auth, tokens, CORS, and endpoints from the client's side of the wire — which is the best way to find out whether I actually understood them. The known cost, which I'm accepting on purpose: GET /expenses is still unbounded, so when pagination lands later I'll have to come back and revise this list UI. Flagged, accepted, moving on.

Let's call it PHASE 4 — The Face:

Scaffold a real React app with Vite
Write my first component and actually understand JSX
Build a login form that holds its own text [controlled inputs + useState]
Call the backend from the browser — and get mugged by CORS
Store the token, and reckon with where to store it
Fetch and render the expense list [useEffect]
Close the three gaps: loading, empty, error
Wire up add / delete / edit — full CRUD from the UI
Fix the bug that made login "do nothing until I refreshed"

First, the new world [everything here is different from the backend]

The backend runs on Python; you install libraries with pip and freeze them into requirements.txt. The frontend has an exact parallel universe, and learning the mapping made the whole thing click:

Node.js is the JavaScript runtime — the "Python interpreter" of the frontend. [I'm on v22.]
npm is Node's package manager — this is pip. [I'm on v11.]
package.json is requirements.txt's counterpart — except it updates itself automatically when you install. No manual freeze step over here. One less habit to remember on this side of the fence.
node_modules/ is venv/ — enormous, machine-specific, and it must never touch git.
Vite [French for "quick," said veet] is the tool that scaffolds the app and runs the hot-reloading dev server. It's the frontend's uvicorn --reload.

Two forks in the road, two flagged shortcuts:

Vite offered me TypeScript or plain JavaScript. I took plain JS. TypeScript is fantastic and production-common, but it's a second new language stacked on top of React, and one new language at a time is plenty. [TypeScript = "know this exists," not now.]
It also asked which linter — Oxlint or ESLint. [A linter is a spell-checker for code: it reads your code without running it and flags likely bugs and sloppy style.] I picked ESLint because it's the industry default — when I hit an error and google it, ESLint results are everywhere. Oxlint is newer and faster but less documented. [Oxlint = know this exists.]

npm create vite@latest frontend -- --template react
cd frontend
npm install
npm run dev

That last command lit up a starter page at http://localhost:5173 with a clicky "count is 0" button — which, I later learned, is useState doing its thing. My first commit of the phase was that untouched scaffold, on its own: a clean "React works" checkpoint I could always fall back to before I started breaking things.

Habit that carried over: before committing, I checked git wasn't about to swallow node_modules. Turns out Vite drops its own .gitignore inside frontend/ — and yes, git supports multiple .gitignore files, one per folder. I didn't take that on faith [never, with git]; I ran git check-ignore frontend/node_modules and it echoed the path back, which is git saying "yep, ignoring that." Verify, don't assume.

Step 1: My first component [JSX has three rules that bite]

A React component is deceptively simple: it's just a JavaScript function, with a Capitalized name, that returns markup. That markup is JSX — it looks like HTML but it's actually JavaScript wearing a costume. I overwrote Vite's demo App.jsx with my own [safe: it's boilerplate, and I'd just committed, so git checkout would bring it back instantly]:

function App() {
  return (
    <div>
      <h1>Smart Expense Manager</h1>
      <p>Frontend is alive.</p>
    </div>
  )
}

export default App

Three JSX rules that trip everyone, now filed away:

One single root element. You can't return two side-by-side tags; wrap them in a parent. [React will yell at you.]
className, not class — because class is a reserved word in JavaScript.
{ } to drop a JS value into markup — {2 + 2} renders 4.

export default App is what lets main.jsx do import App from './App.jsx' — the JS version of exposing a name so another module can import it. I saved the file, and the browser instantly swapped to my text without a refresh. That's hot reload, and it's addictive.

Step 2: A login form that holds its own text [useState]

My instinct was to store what the user types in a normal variable — let email = ''. Wrong, and here's the precise why: React only updates the screen when it re-renders, and a plain variable changing doesn't trigger one. The box would go stale.

The fix is useState, a hook — a special function that lets a component remember a value across re-renders and re-render when that value changes.

import { useState } from 'react'

function App() {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  function handleSubmit(event) {
    event.preventDefault()
    console.log('Logging in with:', email, password)
  }

  return (
    <div>
      <h1>Smart Expense Manager</h1>
      <form onSubmit={handleSubmit}>
        <input
          type="email"
          placeholder="Email"
          value={email}
          onChange={(event) => setEmail(event.target.value)}
        />
        <input
          type="password"
          placeholder="Password"
          value={password}
          onChange={(event) => setPassword(event.target.value)}
        />
        <button type="submit">Log in</button>
      </form>
    </div>
  )
}

New ideas, in plain language:

const [email, setEmail] = useState('') returns a pair — the current value and a setter. That [...] unpacking is array destructuring. The iron rule: never reassign email directly — always call setEmail(...). The setter is what tells React "this changed, re-render."
Controlled input — the two-way loop that is the React form pattern: value={email} makes the box always display state, onChange pushes every keystroke back into state. State is the single source of truth; the input just mirrors it.
import { useState } with braces is a named import; import App without braces is a default import. The braces are the tell.

And the one that will get me someday:

Gotcha #1 — event.preventDefault() is not optional. By default, submitting an HTML form makes the browser reload the entire page [a genuine 1990s behavior]. In a React app that wipes all your state and blanks the screen. preventDefault() cancels it so I stay in control. I know for a fact I'll forget this line one day and watch my page flash — but now I'll know exactly why.

I opened DevTools, typed in both boxes [text appeared as I typed — the loop works], clicked Log in, and watched Logging in with: ... print to the console with no page reload. First real interaction, done.

Step 3: Call the backend — and get mugged by CORS

Now the browser had to actually talk to FastAPI. Two new concepts collided here.

First, async / await and fetch. Network calls take time, and JavaScript can't freeze the browser waiting. So fetch [the browser's built-in HTTP client — the JS version of Python's requests] returns a Promise, an "I'll have your answer later" placeholder. await pauses this function until it resolves, and any function using await must be marked async [same word as FastAPI's async def].

Second — and this is the single biggest gotcha of the whole phase:

Gotcha #2 — the login endpoint is the odd one out: it wants FORM data, not JSON. My /auth/login uses OAuth2PasswordRequestForm, which reads application/x-www-form-urlencoded, not JSON. Send it JSON and you get a baffling 422. So I built the body with URLSearchParams and set the matching Content-Type. Bank this: the OAuth2 login endpoint is form-encoded; every other endpoint in my API speaks JSON. Mixing these two up is the classic source of 422s.

async function handleSubmit(event) {
  event.preventDefault()
  const formBody = new URLSearchParams()
  formBody.append('username', email)   // OAuth2 calls the field "username" — I put my email there
  formBody.append('password', password)

  const response = await fetch('http://localhost:8000/auth/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: formBody,
  })
  const data = await response.json()
  console.log('Status:', response.status, 'Body:', data)
}

My mentor predicted this would fail, and it did — with a big red wall:

Gotcha #3 — CORS, the thing my roadmap warned trips up everyone. Access to fetch at 'http://localhost:8000/auth/login' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header... My frontend runs on port 5173, my backend on 8000 — different port means the browser considers them different origins, and it refused to let my code read the response.

CORS [Cross-Origin Resource Sharing] is a browser security feature, not a bug in my code. The scenario it prevents: you're logged into your bank in one tab, you visit a sketchy site in another, and that site's JavaScript quietly fires requests at your bank using your session. To stop that, the browser won't let JS on origin A read a response from origin B unless server B explicitly says it allows A. Server B says so with an Access-Control-Allow-Origin header — which my FastAPI wasn't sending. Getting the error actually meant my request was leaving the browser correctly; the backend just hadn't granted permission yet.

The fix lives on the backend, via FastAPI's CORSMiddleware [a middleware is code that wraps every request/response — perfect for stamping a header onto everything]. Bonus: it ships inside FastAPI, so no install, no requirements.txt change this time.

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173"],  # the whitelist — explicit, never "*"
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Two decisions worth stating:

Never allow_origins=["*"]. It defeats the point, and the browser flat-out forbids "*" together with allow_credentials=True. Always list explicit origins. [Flagged shortcut: I hardcoded the dev URL. Production reads allowed origins from an env var and lists the real Vercel domain — that's my Phase 9 deploy task.]
allow_headers=["*"] matters because I'm about to start sending an Authorization header on every protected request.

uvicorn hot-reloaded, I clicked Log in again, and the CORS error was gone — replaced by a clean 401, because my dev database was freshly regenerated and had zero users. A 401 round-trip was a success: the browser-to-backend pipe now worked end to end. I registered a test user through /docs, typed the same credentials into my form, and got 200 with a glorious { access_token: "eyJ...", token_type: "bearer" }. My React app had fetched its own JWT.

Step 4: Store the token [the one real security decision this phase]

The token vanished the instant handleSubmit finished. I needed to keep it — every future request has to attach it, and a refresh shouldn't log me out. Enter localStorage: a tiny per-origin key-value store built into the browser, persists across reloads, dead-simple API [setItem, getItem, removeItem], values are always strings.

if (response.ok) {
  const data = await response.json()
  localStorage.setItem('token', data.access_token)
}

[response.ok is a boolean that's true for any 2xx — the clean way to ask "did this succeed?" instead of eyeballing status numbers.]

Here's where I put the security hat back on, because it genuinely matters:

localStorage is readable by any JavaScript running on my page. So if an attacker ever injects a script into my app — that's an XSS [cross-site scripting] attack — they can read the token straight out of storage and impersonate the user. That's the real risk, stated plainly.

What I did [flagged learning shortcut]: store the JWT in localStorage. Simple, easy to inspect while learning, sidesteps cookie/CORS-credential complexity.
What production does: store it in an httpOnly, Secure, SameSite cookie. httpOnly means JavaScript literally cannot read it, so even a successful XSS can't steal it, and the browser attaches it automatically. [Know this exists. Not building it now.]

React's own defense is worth knowing too: it auto-escapes any text you render, which neutralizes most XSS by default. The danger zone is a prop literally named dangerouslySetInnerHTML — the scary name is the warning. Don't use it and you dodge the common trap.

I logged in, opened DevTools → Application → Local Storage, saw my token key sitting there, refreshed the page, and it survived. That persistence is the whole point.

Step 5: The expense list [useEffect, and the infinite-loop trap]

Reading data needs useEffect, and I'm glad I learned the trap before hitting it. A component function re-runs on every render. So you can't just drop a fetch in the component body — it'd fire on every render, hammer the API, and [if it sets state] spin into an infinite re-render loop.

useEffect lets you say "run this as a side effect, but only at specific times." The dependency array [second argument] controls when:

[] empty → run once, right after the component first mounts. Exactly what "fetch when the page loads" wants.
[x] → also re-run when x changes.
omitted entirely → run after every render. The infinite-loop trap. Don't.

One quirk: the effect function itself can't be async, so the pattern is to define an async function inside it and call it immediately.

import { useState, useEffect } from 'react'

function ExpenseList() {
  const [expenses, setExpenses] = useState([])

  useEffect(() => {
    async function fetchExpenses() {
      const token = localStorage.getItem('token')
      const response = await fetch('http://localhost:8000/expenses', {
        headers: { Authorization: `Bearer ${token}` },
      })
      const data = await response.json()
      setExpenses(data)
    }
    fetchExpenses()
  }, [])
  // ...
}

That `Bearer ${token}` is a template literal — backticks let you embed a variable with ${...}. It produces the exact string my /docs "Authorize" button sends, which is how the app proves who it is on every protected request. The fetch came back with a clean empty array [] — correct, since my test user had no expenses yet. Authentication working from the client side, first time.

Step 6: The three gaps nobody builds [loading, empty, error]

This is the heart of the phase. And it starts with a gotcha that burns everyone:

Gotcha #4 — fetch does NOT throw on a 404 or 500. It only rejects when the network itself fails [server down, CORS block]. A 401 or 500 is, to fetch, a perfectly "successful" round-trip that happens to carry a bad status. So you have to check response.ok yourself and deliberately throw on a bad status. Coming from Python's requests, this genuinely surprised me.

I handled both failure kinds with try / catch / finally [same shape as Python]. finally runs no matter what — the perfect home for setLoading(false), so a loading spinner can never get stuck on screen. And I rendered the states with early returns in strict priority order: loading → error → empty → list.

const [expenses, setExpenses] = useState([])
const [loading, setLoading] = useState(true)
const [error, setError] = useState(null)

useEffect(() => {
  async function fetchExpenses() {
    const token = localStorage.getItem('token')
    try {
      const response = await fetch('http://localhost:8000/expenses', {
        headers: { Authorization: `Bearer ${token}` },
      })
      if (!response.ok) {
        throw new Error(`Request failed: ${response.status}`)
      }
      const data = await response.json()
      setExpenses(data)
    } catch (err) {
      setError('Could not load expenses. Please try again.')
      console.error(err)
    } finally {
      setLoading(false)
    }
  }
  fetchExpenses()
}, [])

The part tutorials skip — I tested the error gap on purpose. I hit Ctrl+C on the backend, refreshed the browser, and instead of a blank frozen page I got my red "Could not load expenses. Please try again." That's the adversarial habit surviving even without the GAN framing: don't just build the happy path, actively try to break it.

Then rendering the list with .map() — the array method that turns each expense object into an <li>. Every mapped element needs a key — a stable unique id so React can track rows across re-renders. Use the database id, never the array index [index breaks the moment the list reorders or an item is removed].

While wiring this, a small honest scope decision surfaced: my mentor's example row showed a category field. My Expense model doesn't have one. Adding it isn't a display tweak — it's a new column, a migration, and schema changes. That's literally what my roadmap's Phase 7 [AI categorization] is for. So I dropped it rather than scope-creep a clean foundation phase. [category → deferred to Phase 7.] My real ExpenseRead returns id, amount, description, spent_on, and timestamps — and a nice detail: because amount is a Decimal, Pydantic serializes it to a string on purpose, to protect money from float rounding.

Step 7: Full CRUD from the UI [add, delete, edit]

Add [POST]. Same JSON pattern I'll use everywhere except login: Content-Type: application/json and body: JSON.stringify({...}). On success, I clear the form and re-fetch the list so the new row appears — letting the server stay the single source of truth. To make that re-fetch reusable, I pulled fetchExpenses out of useEffect into the component body, so both the initial load and every post-write refresh could call it.

async function handleAdd(event) {
  event.preventDefault()
  const token = localStorage.getItem('token')
  const response = await fetch('http://localhost:8000/expenses', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token}`,
    },
    body: JSON.stringify({ description, amount, spent_on: spentOn }),
  })
  if (response.ok) {
    setDescription(''); setAmount(''); setSpentOn('')
    fetchExpenses()
  }
}

[A lovely bit of luck: an <input type="date"> gives a date-picker whose value is already a "YYYY-MM-DD" string — exactly what my Python date field wants, zero conversion.]

Adding the always-visible form forced a rendering upgrade. Early returns worked when the whole component was one state, but the form has to show even in the empty state. So I switched to inline conditional rendering with &&:

{loading && <p>Loading expenses…</p>}
{error && <p style={{ color: 'red' }}>{error}</p>}
{!loading && !error && expenses.length === 0 && <p>No expenses yet.</p>}
{!loading && !error && expenses.length > 0 && ( /* the list */ )}

The lesson worth banking: early-return when the entire component is one state; inline && when only part of the UI changes.

Gotcha #5 — one missing ! showed two contradictory states at once. For a while my app displayed "Could not load expenses" and "No expenses yet" simultaneously — which is impossible; those are supposed to be mutually exclusive. The cause was hilariously small: my empty-state guard was missing the !error check. One character [!] fixed it. A whole render bug lived in a single missing symbol.

Delete [DELETE]. Two things I hadn't met:

Gotcha #6 — a 204 has no body, so don't parse one. My DELETE returns 204 No Content — by definition, empty. Calling response.json() on it would throw. Just check response.ok and move on.

Gotcha #7 — passing an argument to a handler needs an arrow wrapper. To delete a specific row I wrote onClick={() => handleDelete(expense.id)}. If I'd written onClick={handleDelete(expense.id)} [no arrow], React would call it immediately during render — deleting everything the instant the list appeared. The arrow hands React a function to call later, on click. Rule of thumb I locked in: no args → pass the reference [onClick={handleLogout}]; need args → wrap in an arrow.

Edit [PATCH]. The biggest UI concept: per-row edit mode. I track which row is editing with a single editingId [null = nobody], and render with a ternary — "if this row is being edited, show inputs; otherwise show text + buttons." Each branch has to return one element, so I wrapped the siblings in a Fragment [<>...</>] — an invisible grouping tag that adds no extra <div> to the page.

PATCH is a partial update: my backend's ExpenseUpdate has all-optional fields, and it saves with payload.model_dump(exclude_unset=True) → setattr → db.commit() → db.refresh(). On success I close edit mode and re-fetch, same source-of-truth habit.

With edit working, I'd hit the phase's finish line: log in through the UI and do full create/read/update/delete without ever opening /docs.

Step 8: The bug that made login "do nothing until I refreshed"

This one deserves its own section because it taught me the deepest React lesson of the phase. My symptom: I'd log in, and nothing happened — until I refreshed the page, at which point it worked perfectly.

The cause, once I understood it, is fundamental:

Gotcha #8 — React does not watch localStorage. My login handler wrote the token to localStorage, but React only re-renders when a piece of state changes. Writing to storage is completely invisible to it. And my ExpenseList fetched only once, on mount — so on a fresh load it fired with Bearer null, failed, and never ran again. Logging in stashed a token, but nothing told React anything had changed. A refresh "fixed" it only because it re-mounted the whole app after the token was already in storage.

The fix was my first taste of lifting state up: the token belongs in App [the parent], because App is what decides between "logged out" and "logged in." I put the token in React state, seeded from storage, and set it on login:

const [token, setToken] = useState(localStorage.getItem('token'))  // survives refresh

// in the login success branch:
localStorage.setItem('token', data.access_token)
setToken(data.access_token)  // <-- THE missing trigger. State change → re-render → instant switch.

// gate the whole UI on it:
if (token) {
  return (
    <div>
      <h1>Smart Expense Manager</h1>
      <button onClick={handleLogout}>Log out</button>
      <ExpenseList />
    </div>
  )
}
// otherwise fall through to the login form

Logout is just login run backwards — clear both copies of the token:

function handleLogout() {
  localStorage.removeItem('token')  // so a refresh won't silently log me back in
  setToken(null)                    // so the gate falls through to the login form
}

Two more real bugs fell out of this, and both are honest lessons:

The stray-render leak. After adding the gated view, logging out still showed the expense list — because an earlier <ExpenseList /> was still sitting in the logged-out return from a previous step. I'd added the new one without removing the old. ExpenseList should appear in exactly one place. A quick file search [it should show up twice: the import + one render] caught it. Lesson: when you restructure, hunt down the leftovers.
Incognito confused me for a minute. Logged in on a normal window, I opened incognito, logged in there, and the two windows behaved independently. That's correct — localStorage is isolated per browser profile, so incognito has its own separate store. [Imagine if it didn't; that'd be a leak.] Two normal tabs share storage but not live React state, so one won't visually update until it refreshes. [Live cross-tab sync via the storage event = know this exists.]

Bonus: so how does clicking "Save" actually change the database?

This confused me, so I'll write down the model that fixed it: there are three separate programs, and none can touch the others' memory.

My React app — JavaScript in the browser. It knows nothing about the database. All it can do is send HTTP requests.
My FastAPI backend — Python in the uvicorn terminal. The only program that talks to the database.
SQLite — the expenses.db file. It only ever hears from the backend.

So the Save button does not save to the database. It sends a PATCH note to the backend asking it to save. The backend checks my token, finds my row [scoped to my user id — my Phase 3 ownership filter riding along], sets the new values, and runs db.commit() — that single line is the actual write to disk. Then it replies 200, and my browser re-fetches so the screen matches what the database now says. Every operation in the app is that same shape: Create = POST + commit, Delete = DELETE + commit, Update = PATCH + commit, Read = GET [no commit — nothing changes]. Once that one round-trip clicked, the whole app made sense.

Stuff I want to remember [the honest takeaways]

The frontend has an exact mirror of the backend's tools: Node = Python, npm = pip, package.json = requirements.txt [but it auto-freezes], node_modules = venv, Vite = uvicorn.
A component is a Capitalized function returning JSX. JSX rules that bite: one root element, className not class, { } for JS values.
useState returns a [value, setter] pair. Never reassign the value — always call the setter. The setter is the only thing that triggers a re-render.
React only re-renders on state change. It does not watch localStorage. This one fact caused my nastiest bug.
Controlled inputs [value + onChange] make state the single source of truth for a form.
event.preventDefault() stops the browser's default full-page reload on form submit. You will forget this once.
CORS is a browser security feature, not a bug in your code. Different port = different origin; the fix is CORSMiddleware on the backend, with an explicit origin whitelist [never "*" with credentials].
The OAuth2 login endpoint is the odd one out — it wants form-encoded data. Everything else speaks JSON. Mixing them up is the classic 422.
fetch does NOT throw on 4xx/5xx. Check response.ok yourself and throw deliberately. Use try/catch/finally, and put setLoading(false) in finally so it can never get stuck.
Build the happy path, then close the three gaps: loading, empty, error — and actually test the error state by killing the backend.
.map() renders lists; every item needs a stable key — use the DB id, never the array index.
&& for show-or-nothing; ternary ? : for A-or-B; Fragments <>...</> to group siblings without an extra <div>.
Passing args to a handler needs an arrow wrapper [() => fn(id)] or it fires during render. No args → pass the reference.
A 204 response has no body — don't call .json() on it.
JWT in localStorage is a flagged shortcut [readable by any JS → XSS risk]. Production uses an httpOnly Secure SameSite cookie. React auto-escapes text; avoid dangerouslySetInnerHTML.
The Save button doesn't save — it asks the backend to. db.commit() is the real write. The browser, the backend, and the database are three separate programs passing notes.
When you restructure, hunt the leftovers — a stray render leaked my list into the logged-out view.
Commit at every green checkpoint, with a subject + a "why." Small and often beats one heroic commit.

Next up: Phase 5. The app now has a memory, a mouth, a lock, and — finally — a face a human can log into and use. But that face is honest to a fault: it's a raw list with no styling, no summaries, and a login that just... stops working after 30 minutes with a confusing error [my JWTs expire, and I don't handle it yet]. Phase 5 is where the face gets some expression — a dashboard, spending insights, and the polish that turns "it works" into "I'd actually use this." That, and I owe this app an "expired-token → send me back to login" fix I flagged and walked away from. See you there.

Teaching My Backend to Lock the Door — FastAPI Auth, Phase 3

Azhar Alvi — Sat, 25 Jul 2026 09:06:27 +0000

Hash the password, hand out a token, and make absolutely sure no one can read someone else's expenses.

So Phase 2 gave my app a mouth. It could finally talk — create, read, update, and delete expenses over real HTTP endpoints, all clicking together through /docs. But there was a giant, deliberately-ignored problem sitting in the middle of it: the door had no lock. Anyone who could reach the server could read, edit, or delete anything. And every expense I created was quietly stamped with the same hardcoded owner — a "dev user" whose id I'd nailed into the code with a # TEMP note and a promise to fix it "in Phase 3."

Well. It's Phase 3. Time to pay that debt.

This is where the app grows a bouncer. The buzzword is auth, which actually hides two jobs that sound the same and aren't: authentication ["who are you?"] and authorization ["okay, but are you allowed to touch this?"]. I went in thinking auth was "add a login form" and came out having learned about one-way hashing, signed tokens, a security bug with the excellent name IDOR, and why the same password can produce two different hashes. Let me dump what I learned [and the parts that tripped me up, because — as usual — there were several].

Auth is the one phase where you have to stop thinking like a builder and start thinking like the person trying to rob you. So every step below is really "here's a way an attacker wins, and here's the gap I closed to stop them."

The structure. Let's call it PHASE 3 — The Lock:

Give the User table somewhere to store a password [a hashed one, never the real thing]
Password hashing helpers — turn a password into something safe to store
POST /auth/register — sign up with a hashed password
Understand what a JWT actually is [it's just a signed string, and it's readable]
POST /auth/login — check the password, hand back a token
get_current_user — the gatekeeper that turns a token back into a user
Lock every expense endpoint and scope it to the logged-in owner
Retire the hardcoded DEV_USER_ID for good
Prove two users can't see each other's data

First, the new ideas [and yes, this time there IS stuff to install]

Unlike Phase 2, this phase actually adds libraries — so the pip freeze habit is back on. Three new tools, in plain language:

passlib [with bcrypt] — the password shredder. bcrypt is the actual algorithm; passlib is the friendly wrapper around it. Its whole job is to turn a password into a hash — a scrambled string you can store safely — using a method that's deliberately slow and salted [more on both of those below].
PyJWT — the token machine. It creates and verifies JWTs, the signed strings that let a user prove "I'm logged in" on every request without re-sending their password. [Gotcha you'll hit: you pip install pyjwt but you import jwt. The names don't match. File that away now.]
python-multipart — an unglamorous helper that lets FastAPI read form data, which the standard login flow uses. You don't call it directly; FastAPI just needs it present.

pip install "passlib[bcrypt]" pyjwt python-multipart
pip freeze > requirements.txt

The quotes around "passlib[bcrypt]" matter — the brackets tell pip to pull bcrypt in as an extra. And the moment you install something, freeze it, so the next machine [including future-you] rebuilds the identical environment.

Step 1: Give users a place to store a password [a hashed one]

Here's the rule that governs this entire phase, and it's worth tattooing somewhere: you never store the password. You store a one-way hash of it.

My User model from Phase 1 had name, email, and timestamps — but no password field at all, because I built it before auth existed. So it needs one new column:

hashed_password: Mapped[str] = mapped_column(String, nullable=False)

Two deliberate choices:

It's called hashed_password, not password. The name is a permanent reminder to everyone [me, in three weeks] that this field holds a hash, never plaintext. If you ever spot raw text in there, something is badly broken.
It's not unique and not indexed [unlike email]. You never look a user up by their hash — you find them by email, then verify the hash in code. Indexing it would be wasted effort.

A new column means a new migration. Same autogenerate → review → apply rhythm from Phase 1:

alembic revision --autogenerate -m "add hashed_password to users"

I reviewed the generated file [op.add_column(... nullable=False)] and then hit the wrinkle that became my first real lesson this phase.

Gotcha #1 — the NOT NULL wall. SQLite refuses to add a NOT NULL column to a table that already has rows, because those existing rows have no value for it. My table had that old seeded dev user in it. Two honest paths: the production way [add the column nullable, backfill every row, then a second migration to flip it to NOT NULL — zero data loss], or the learning way [my only data was throwaway, so wipe it and rebuild]. My mentor made me say out loud that we were taking a shortcut. I took it — but now I know the real move for when the data actually matters.

⚠️ Destructive-command warning [the first of this phase]: rebuilding from scratch deletes every local row. Safe here only because it's junk dev data. Rather than delete the .db file by hand, I stayed inside Alembic — which also proves my whole migration chain works end to end:

alembic downgrade base   # drops everything back to empty [the destructive line]
alembic upgrade head     # replays all migrations onto empty tables

Step 2: The hashing helpers [hashing is NOT encryption]

Before I could register anyone, I needed two tiny functions: one to hash a password on the way in, one to verify a login attempt later. Best practice says security code lives in its own file, so this is a new security.py:

from passlib.context import CryptContext

pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")


def hash_password(password: str) -> str:
    return pwd_context.hash(password)


def verify_password(plain_password: str, hashed_password: str) -> bool:
    return pwd_context.verify(plain_password, hashed_password)

The single most important concept here — and it took a beat to click:

Hashing is one-way. Encryption is two-way. You can encrypt something and later decrypt it back. You can hash a password, but you can never turn the hash back into the password. That's the entire point: even I, running the server, can't see anyone's password. If my whole database gets stolen, the attacker gets a pile of useless $2b$... strings, not passwords. That's the first gap closed.
bcrypt is deliberately slow. Sounds like a bug; it's a feature. Slowness makes brute-forcing millions of guesses painfully expensive for an attacker while costing a real login a few harmless milliseconds.
bcrypt auto-salts. It mixes a random value into every hash, so two people with the same password get different hashes. That kills "rainbow table" attacks [precomputed hash lookups]. I proved this to myself: hashing "supersecret123" twice gave two totally different strings. Same input, different output — the salt, visibly doing its job.
deprecated="auto" is the sneaky-clever bit. Because every hash records which algorithm made it [the $2b$ prefix is bcrypt's ID card], I can add a newer algorithm years from now and passlib will keep verifying old hashes and silently upgrade them the next time each user logs in. Nobody gets locked out, nobody resets their password. Algorithm agility, for one word of config.

I tested it in a plain python shell: hash_password("supersecret123") gave a long $2b$... string, verify_password("supersecret123", h) returned True, and verify_password("wrong", h) returned False. Then the version gods showed up.

Gotcha #2 — the 72-byte error on a 14-character password. My first real hash blew up with ValueError: password cannot be longer than 72 bytes. My password was 14 characters. What?! The culprit: passlib 1.7.4 is old and unmaintained, and modern bcrypt [4.1+] changed an interface it relies on. On its first run, passlib runs an internal self-test that trips the new bcrypt's 72-byte guard — before my password is ever touched. The fix was to pin bcrypt to the last version passlib understands:
pip install "bcrypt==4.0.1"
pip freeze > requirements.txt
This was also the moment "why do we freeze?" stopped being abstract — without the pin, a fresh install would grab the broken-for-me newest bcrypt all over again. [The modern alternative is a library called pwdlib; passlib is on its way out. Noted for a future refactor.]

Step 3: POST /auth/register [where the hash finally gets used]

Two schemas, exactly like Phase 2's input/output split — but with one security rule bolted on. In schemas.py:

class UserCreate(BaseModel):
    """What a client sends to register."""
    name: str = Field(min_length=1, max_length=100)
    email: str
    password: str = Field(min_length=8)


class UserRead(BaseModel):
    """What the server sends back — no password, no hash, EVER."""
    id: int
    name: str
    email: str
    created_at: datetime

    model_config = ConfigDict(from_attributes=True)

Look at what UserRead is missing: the password and the hash. This is a real gap — if the stored hash ever showed up in an API response, an attacker who can read responses gets a head start on cracking it. Leaving it out of the output schema makes that leak structurally impossible. Same trick as response_model=ExpenseRead in Phase 2, now doing security work.

The endpoint, in main.py:

@app.post("/auth/register", response_model=UserRead, status_code=status.HTTP_201_CREATED)
def register(payload: UserCreate, db: Session = Depends(get_db)):
    existing = db.scalars(select(User).where(User.email == payload.email)).first()
    if existing is not None:
        raise HTTPException(status_code=409, detail="Email already registered")

    user = User(
        name=payload.name,
        email=payload.email,
        hashed_password=hash_password(payload.password),
    )
    db.add(user)
    db.commit()
    db.refresh(user)
    return user

hashed_password=hash_password(payload.password) is the one line that makes this safe. The plaintext exists only long enough to be hashed, right here, and is never stored. What lands in the database is the $2b$... string.
The /auth/ prefix namespaces auth routes together — tidy as the API grows. [The neater-still version is a separate APIRouter file; leaving that for later so I'm not juggling files mid-concept.]
409 Conflict is the precise code for "your request is fine, but it clashes with something that already exists" — here, a taken email. More specific than a generic 400. [The fully robust version wraps the insert in a try/except IntegrityError to close a tiny race where two people register the same email at the same instant; the DB's unique constraint still protects integrity either way. Noted, not built.]

Tested through /docs: register → 201, and the response showed id, name, email, created_at and — crucially — no hashed_password. Registering the same email again → 409.

Step 4: What a JWT actually is [read this before you trust one]

This was the concept I most needed to get before writing more code. A JWT [JSON Web Token, said "jot"] is just a signed string the server hands you at login. You send it back on every future request, and it proves "I'm logged in" — without the server having to remember sessions. The token itself carries the proof.

It has three parts separated by dots: header.payload.signature.

Header — which signing algorithm was used [I used HS256].
Payload — the "claims," i.e. the data. I put in sub [subject — who the token is about; I store the user's id] and exp [expiry].
Signature — the header and payload, signed with my secret key.

Here's the thing that reframed everything for me: the payload is only base64-encoded, not encrypted. Anyone who grabs the token can read it — paste one into jwt.io and you'll see the user id in plain text. So the rule is: never put anything secret in a JWT. What a token buys you isn't secrecy — it's integrity. Change one character of the payload [say, to a different user's id] and the signature no longer matches, so the server rejects it. An attacker can't forge a valid signature because only my server knows the secret key.

Which is exactly why that key can never leak. If someone learns my SECRET_KEY, they can mint valid tokens for any user — a total bypass. So it lives in .env [already gitignored since Phase 0], generated with real randomness:

python -c "import secrets; print(secrets.token_hex(32))"

SECRET_KEY=that_64_char_hex_value
ACCESS_TOKEN_EXPIRE_MINUTES=30

That 30-minute expiry closes another gap: a stolen token stops working within half an hour instead of forever. [Real apps pair a short access token with a longer "refresh token" so users aren't logged out constantly. Not building refresh tokens this phase — that'd be over-engineering right now.]

Then I wrote the token minter in security.py:

def create_access_token(subject: str) -> str:
    expire = datetime.now(timezone.utc) + timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
    payload = {"sub": subject, "exp": expire}
    return jwt.encode(payload, SECRET_KEY, algorithm=ALGORITHM)

Note the timezone-aware UTC expiry — same discipline as Phase 1's timezone=True columns. Auth timestamps must be unambiguous across servers.

Gotcha #3 — the misspelled keyword that wasn't a version bug. Setting up CryptContext earlier, I hit KeyError: unknown CryptContext keyword. I assumed another bcrypt version mess. But my mentor made me read the traceback bottom-up first — and the last line said it plainly: an argument I passed doesn't exist. I'd typed depreciated [the accounting word, with an i] instead of deprecated. Case-and-spelling-sensitive libraries do not forgive. Reading the traceback saved me from "fixing" something that was never broken.

Gotcha #4 — a .env file does nothing on its own. My SECRET_KEY = os.environ["SECRET_KEY"] crashed with a KeyError. Turns out I'd been reading env vars with os.getenv all along but never actually loading the .env file into the environment — my DATABASE_URL only "worked" because it had a default fallback that quietly kicked in. A .env file is just text; something has to copy it into the environment first. That something is load_dotenv():
from dotenv import load_dotenv
load_dotenv()   # must run BEFORE anything reads a variable
Lesson that stuck: loading and reading are two different jobs. load_dotenv() loads; os.getenv() reads. And my strict, no-fallback SECRET_KEY line is what exposed the gap the fallback had been hiding — fail-fast earning its keep.

Step 5: POST /auth/login [check the password, hand back a token]

This is where hashing and JWTs meet. I built login the standard FastAPI way, with OAuth2PasswordRequestForm — which, bonus, lights up the green Authorize button in /docs.

@app.post("/auth/login", response_model=Token)
def login(
    form_data: OAuth2PasswordRequestForm = Depends(),
    db: Session = Depends(get_db),
):
    user = db.scalars(select(User).where(User.email == form_data.username)).first()
    if user is None or not verify_password(form_data.password, user.hashed_password):
        raise HTTPException(
            status_code=401,
            detail="Incorrect email or password",
            headers={"WWW-Authenticate": "Bearer"},
        )
    access_token = create_access_token(subject=str(user.id))
    return {"access_token": access_token, "token_type": "bearer"}

The quirk everyone hits: the OAuth2 spec calls the field username, but I put the email there. So at login you type your email into the box labeled "username." Normal in FastAPI land.
The vague error is on purpose. Whether the email doesn't exist or the password is wrong, I return the exact same 401 with the same message. If I distinguished them, an attacker could probe which emails are registered — a leak called user enumeration. One generic message, closed. Do this now, it's free.
subject=str(user.id) stamps the user's id into the token's sub claim. That breadcrumb is the whole point — it's how the next step figures out who a request is from, with no password involved.

The docs also show grant_type, scope, client_id, client_secret fields — all part of the full OAuth2 spec, all safely ignorable for my app. Only username and password matter here.

Tested: right email + password → 200 with a token; wrong password → 401. And it taught me a bit of Python grammar I'd been fuzzy on — : describes [amount: Decimal, a dict pair {"key": "value"}, the : that opens a block] while = assigns [x = 5, or a keyword arg status_code=401]. Same word can flip: subject: str in a definition vs subject=... in a call.

Step 6: get_current_user [the gatekeeper]

This is the piece every locked endpoint leans on. It turns a token back into a real, live user — the concrete form of authentication. First a decode helper in security.py:

def decode_access_token(token: str) -> dict:
    return jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])

jwt.decode does two jobs at once: verifies the signature [proving I minted it, untampered] and checks the exp [rejecting expired tokens]. Either failure raises. Then the dependency in main.py:

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="auth/login")


def get_current_user(
    token: str = Depends(oauth2_scheme),
    db: Session = Depends(get_db),
) -> User:
    credentials_exception = HTTPException(
        status_code=401,
        detail="Could not validate credentials",
        headers={"WWW-Authenticate": "Bearer"},
    )
    try:
        payload = decode_access_token(token)
        user_id = payload.get("sub")
        if user_id is None:
            raise credentials_exception
    except jwt.InvalidTokenError:
        raise credentials_exception

    user = db.get(User, int(user_id))
    if user is None:
        raise credentials_exception
    return user

OAuth2PasswordBearer automatically pulls the token out of the incoming Authorization: Bearer <token> header [401 if it's missing] and is what finally enables the Authorize button.
One except jwt.InvalidTokenError covers a bad signature, a malformed token, and an expired one [expiry raises a subclass], all funnelling to the same generic 401. No-leak discipline again.
db.get(User, ...) fetches the actual user rather than blindly trusting the token — so a deleted user's leftover token stops working. Returning the User object is the magic: any endpoint that depends on this gets the logged-in user handed straight to it.

I proved it with a throwaway GET /auth/me that just returns current_user: authorized → 200 with my user; no token → 401.

Gotcha #5 — case-sensitivity, twice. First Oauth2PasswordBearer is not defined, then again — because "OAuth" is an acronym and both the O and the A are uppercase: OAuth2PasswordBearer. I'd lowercased the A. Python doesn't care that it's "obviously" the same word.

Gotcha #6 — order matters for dependencies. I also hit get_current_user is not defined on an endpoint. Not a typo this time — an ordering problem. Python evaluates Depends(get_current_user) in the function's default arguments the moment it reads the def line, so get_current_user has to be defined above any endpoint that uses it. Moved the gatekeeper up near the top of main.py, above the routes. [Same reason get_db has always worked — defined before its consumers.]

Step 7: Lock the endpoints and scope them to the owner [the boss fight]

This is what the whole phase was building toward — and it's the real difference between authentication [we know who you are] and authorization [you may only touch your own rows]. Every expense endpoint gets the same two changes: add current_user: User = Depends(get_current_user), then use current_user.id — for writes, stamp it; for reads, filter by it.

Create finally retires the shortcut:

expense = Expense(**payload.model_dump(), user_id=current_user.id)   # was DEV_USER_ID

And the isolation-critical read — fetch by id AND owner:

@app.get("/expenses/{expense_id}", response_model=ExpenseRead)
def get_one_expense(
    expense_id: int,
    db: Session = Depends(get_db),
    current_user: User = Depends(get_current_user),
):
    expense = db.scalars(
        select(Expense).where(
            Expense.id == expense_id,
            Expense.user_id == current_user.id,
        )
    ).first()
    if expense is None:
        raise HTTPException(status_code=404, detail="Expense not found")
    return expense

That double .where(...) closes the scariest gap in the phase — IDOR [Insecure Direct Object Reference]: the bug where a logged-in User A simply asks for User B's expense by its id. Because the query filters on user_id too, A's request for B's row returns nothing → a clean 404. The ownership check lives in the query itself, so I literally cannot forget it later. The list, PATCH, and DELETE endpoints all got the same treatment [filter the list by owner; fetch-scoped-by-owner before updating or deleting], so it's impossible to even load someone else's row to change it.

Two small but real decisions:

404, not 403, when the row isn't yours. Saying 403 ["that exists, but you can't have it"] would leak that the id exists. 404 reveals nothing. Same no-leak instinct as the login error.
db.scalars(...) + .first() / .all() — db.scalars() hands me clean model objects [not row-tuples], .first() gives one object or None [get-one], .all() gives a list [the list endpoint]. Different endings for different needs.

Then the symbolic finish line — deleting the hardcoded owner. But not before checking it's actually unused:

grep -rn "DEV_USER_ID" .

Habit worth keeping: grep-before-delete. It turns "I think it's unused" into "I've confirmed it's unused." Only the definition line showed up, so I deleted it. DEV_USER_ID is officially retired — 3 phases after I promised it would be.

Step 8: Prove it [the part tutorials skip]

Writing auth code isn't the same as verifying auth works. So I put on the attacker hat and ran the isolation proof my roadmap demanded, entirely through /docs:

Registered a second user, Bob.
As User A: created an expense [id 1], confirmed GET /expenses showed only mine.
Logged out, authorized as Bob — the attacker:
- GET /expenses → empty list []. Bob has nothing. [If A's expense showed up here, isolation was broken.]
- GET /expenses/1, PATCH /expenses/1, DELETE /expenses/1 → 404, 404, 404. Bob can't read, edit, or delete A's row even though he knows its id.
Back as User A: GET /expenses/1 → 200, untouched. Bob's attacks never landed.

Bob is a perfectly valid, authenticated user — and still can't touch A's data. That's the gap closed, and it's the difference between authentication and authorization made concrete. Passing this test is the moment the phase actually ended.

Stuff I want to remember [the honest takeaways]

Never store a password. Store a one-way hash. Hashing ≠ encryption — there's no "decrypt" button, and that's the point.
bcrypt is deliberately slow and auto-salted — same password, different hash every time.
A JWT's payload is readable, not encrypted. Never put secrets in it. What it gives you is integrity, guarded by a signature only your server can produce.
The SECRET_KEY leaking = total auth bypass. It lives in .env, never in git, and it's generated with real randomness.
Short token expiry [exp] limits the damage of a stolen token.
401 = "you failed to authenticate." For "that's not yours," return 404, not 403 — 403 leaks that the thing exists.
Keep login and validation errors vague and identical — specific ones leak which emails/rows exist [user enumeration].
Put the ownership filter in the query [.where(user_id == current_user.id)], not in an afterthought check you can forget.
os.getenv reads env vars; load_dotenv() loads the .env file. Different jobs — you need both.
Dependencies must be defined above the endpoints that use them — default args evaluate at def time.
Read tracebacks bottom-up; the last line is the real error. It'll save you from fixing the wrong thing.
grep before you delete. Confirm dead code is actually dead.
Freeze after every install — and sometimes you have to pin a version [bcrypt==4.0.1] to keep an older library happy.
When you cut a corner, label it — and Phase-N-later, actually go back and pay it off. DEV_USER_ID, you will not be missed.

Next up: Phase 4. The app now has a memory, a mouth, and a lock on the door. It knows who you are and only shows you your own stuff. What it doesn't have yet is a way to make sense of all that data at scale — filtering, sorting, pagination, maybe some summaries. If Phase 3 gave the app a bouncer, Phase 4 teaches it to actually organize the room. See you there.

Teaching My Backend to Listen and Reply — FastAPI CRUD, Phase 2

Azhar Alvi — Wed, 22 Jul 2026 09:38:53 +0000

Validate what comes in, shape what goes out, and give every outcome its proper status code.

So Phase 1 gave my app a memory — a real database that remembers users and expenses even after a restart. Small problem: the only way to actually talk to it was a Python script I ran by hand. The app could remember things, but it was mute. Nobody on the internet could add an expense, list their spending, or delete a typo.

Phase 2 fixes that. This is where the app grows a mouth — real HTTP endpoints you hit through the browser. The buzzword is CRUD: Create, Read, Update, Delete. The four things basically every app does to data. I went in thinking "it's just four functions, how hard can it be" and came out having learned about request/response contracts, dependency injection, and roughly six different HTTP status codes — mostly by triggering them wrong first. Let me dump what I learned [and the parts that tripped me up, because there were, uh, several].

The Structure is as follows. Lets call it PHASE 2 — The Endpoints:

Set up the request/response contracts (two Pydantic schemas: one for input, one for output)
Build a session dependency so every request gets a safe, auto-closing DB connection
POST — create an expense
GET — list them all + fetch one [with a proper 404]
PATCH — update just the fields that changed
DELETE — remove one cleanly

First, the two new ideas [and no, nothing to install this time]

Phase 1 had two new libraries. Phase 2 has two new ideas — and the nice part is there's nothing to pip install, because Pydantic already ships inside FastAPI. [Which means requirements.txt didn't change this phase. Still worth knowing the freeze habit is only for phases where you actually install something.]

Pydantic — the bouncer at the door. Your SQLAlchemy models describe how data is stored; Pydantic describes the shape data must have to cross the border of your API. It checks types, rejects garbage, and turns raw JSON into a clean Python object before it gets anywhere near your database.
Dependency injection — a fancy name for a simple deal. Instead of each endpoint opening its own database session and hoping to remember to close it, you write "how to get a session" once, and every endpoint just declares "I need one." FastAPI runs it for you and cleans up after. You'll see it as Depends(...).

Step 1: Two contracts — one for input, one for output

The single biggest lesson of this phase: you do not use one model for both the data coming in and the data going out. Two separate Pydantic schemas, on purpose. This lives in a new file, schemas.py:

from datetime import date, datetime
from decimal import Decimal
from pydantic import BaseModel, ConfigDict, Field


class ExpenseCreate(BaseModel):
    """What the CLIENT is allowed to send."""
    amount: Decimal = Field(gt=0)
    description: str = Field(min_length=1, max_length=255)
    spent_on: date


class ExpenseRead(BaseModel):
    """What the SERVER sends back — includes DB-generated fields."""
    id: int
    amount: Decimal
    description: str
    spent_on: date
    created_at: datetime
    updated_at: datetime

    model_config = ConfigDict(from_attributes=True)

Why two, and not one? Because input and output have genuinely different jobs:

ExpenseCreate (input) contains only the fields a client is allowed to send. Notice what's missing: no id, no created_at, no updated_at. Those are decided by the database, not the caller. Letting a client send its own id is a classic foot-gun.
ExpenseRead (output) is what you send back, and it does include those server-generated fields.
Field(gt=0) is Pydantic validating for me: an amount of 0 or -5 gets auto-rejected with a clean error. min_length does the same for text. The bouncer, doing its job.
model_config = ConfigDict(from_attributes=True) is the one line that lets Pydantic build the output straight from my SQLAlchemy object [reading .id, .amount etc. as attributes]. In Pydantic v1 this was orm_mode; v2 renamed it to from_attributes. Just know it exists — you'll feel why it matters in Step 3.

And yep, amount stays Decimal here too. Same Phase 1 rule: money never touches a float, not even at the API boundary.

A quick detour: who owns this expense?

Before I could create anything, I hit a wall that's actually a good lesson. My Expense has a user_id foreign key — the database will reject any expense that doesn't point at a real user. But I haven't built login yet [that's Phase 3]. So… who's the owner?

The honest answer: I cheated, on purpose, and wrote down that I cheated.

DEV_USER_ID = 5  # TEMP: Phase 3 replaces this with the authenticated user

I seeded one "dev user" and hardcoded its id as the owner of every expense. In a real app the owner comes from whoever's logged in. But the whole point of learning one thing at a time is not tangling auth into CRUD. So I structured it so Phase 3 is a one-line swap: DEV_USER_ID → current_user.id. Shortcut taken, shortcut labeled.

Gotcha #1: My first attempt to seed the dev user blew up with NOT NULL constraint failed: users.name. My User model requires a name, and I hadn't given one. Same rule as always — if a column is required, you have to supply it. [Bonus: the failed insert did a clean ROLLBACK, so no half-broken row got saved. The transaction safety I read about in Phase 1, actually doing its thing.]

Step 2: The session dependency [write it once, never leak a connection]

Every endpoint needs a database session, and every session must close afterward — even if the request explodes halfway through. So instead of copy-pasting that logic into five endpoints, it goes in database.py once:

from collections.abc import Generator
from sqlalchemy.orm import Session


def get_db() -> Generator[Session, None, None]:
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

The weird-looking part is the yield inside a try/finally. A normal function returns and it's done. This one yields the session out to my endpoint, pauses while the endpoint runs, then comes back and runs the finally block no matter what. That finally is the whole point: db.close() is guaranteed to run on success and on error, so a session can never leak. FastAPI understands this pattern and drives it for me. [I don't fully grok generators yet, and that's fine — for now: yield = "hand it out, then come back and clean up."]

Step 3: POST — create an expense [it all comes together]

This is where Pydantic, the session dependency, and my model finally click into one endpoint. It goes in main.py, where app lives:

from fastapi import Depends, status
from sqlalchemy.orm import Session
from database import get_db
from models import Expense
from schemas import ExpenseCreate, ExpenseRead


@app.post("/expenses", response_model=ExpenseRead, status_code=status.HTTP_201_CREATED)
def create_expense(payload: ExpenseCreate, db: Session = Depends(get_db)):
    expense = Expense(**payload.model_dump(), user_id=DEV_USER_ID)
    db.add(expense)
    db.commit()
    db.refresh(expense)
    return expense

Every line is pulling weight, and it took me a minute to appreciate that:

The @app.post(...) decorator is the wiring. @ means "attach behavior to this function" — here, "when a POST hits /expenses, run me." I write the logic; the decorator handles reading the request and sending the response.
response_model=ExpenseRead runs whatever I return through the output schema before sending it. This is what stops internal fields from ever leaking — even if my model grew a secret column tomorrow, only ExpenseRead's fields go out.
status_code=201 because REST says "created" is a 201, not a plain 200. Small thing, correct thing.
payload: ExpenseCreate — just by type-hinting the parameter, FastAPI auto-reads the JSON body, validates it against the schema, and hands me a clean object. I never touch raw JSON.
Depends(get_db) — the Step 2 dependency in action. I just get a ready-to-use db that closes itself.
`Expense(payload.model_dump(), user_id=DEV_USER_ID)** — model_dump() turns the validated object into a dict, **` unpacks it into the model, and I tack on the owner. [That's the one line Phase 3 will change.]
add → commit → refresh — stage it, write it, then re-read it so the DB-generated id/timestamps get populated on my object before I return it.

Gotcha #2: My first POST returned a 500 with 'ExpenseCreate' object has no attribute 'model'. The cause was a one-character typo: I'd written payload.model.dump() [a dot] instead of payload.model_dump() [an underscore]. model_dump() is a single Pydantic v2 method name, not two things chained with a dot. [If you see .dict() in old tutorials, that's the v1 name for the same thing.]

Gotcha #3: Next 500: NOT NULL constraint failed: expenses.spent_on. My Expense requires spent_on, but my input schema didn't include it, so nothing got sent for it. Fix: add spent_on to ExpenseCreate. The rule crystallized here — every required DB column must exist in the input schema. Whack-a-mole ends the moment you check your model for all its NOT NULL columns up front.

Step 4: GET — list them all, and fetch one [meet the 404]

Two reads, two conventions: GET /expenses returns a list; GET /expenses/{id} returns one.

from typing import List
from fastapi import HTTPException
from sqlalchemy import select


@app.get("/expenses", response_model=List[ExpenseRead])
def list_expenses(db: Session = Depends(get_db)):
    return db.scalars(select(Expense)).all()


@app.get("/expenses/{expense_id}", response_model=ExpenseRead)
def get_expense(expense_id: int, db: Session = Depends(get_db)):
    expense = db.get(Expense, expense_id)
    if expense is None:
        raise HTTPException(status_code=404, detail="Expense not found")
    return expense

db.scalars(select(Expense)).all() is the same SQLAlchemy 2.0 read from Phase 1, just returning the whole list.
db.get(Expense, id) is the shortcut for "fetch one by primary key" — returns the object, or None if there's no such id.
raise HTTPException(404) is the important habit. If I let None sail through, the code crashes trying to serialize nothing → a 500, which wrongly implies I broke. Instead I deliberately raise a 404 Not Found: "your request was fine, that thing just isn't here." raise [not return] stops the function dead and sends the error.

And here's the coolest thing I learned this phase, entirely by fat-fingering the docs:

Ask for /expenses/abc [a string where an int belongs] → you get a 422. FastAPI checks the path type before your function even runs and decides the request itself is malformed.
Ask for /expenses/999999 [a valid integer that doesn't exist] → you get a 404. The request was well-formed, so the function runs, finds nothing, and raises 404.

So: 422 = "your request was malformed" vs 404 = "your request was fine, the resource doesn't exist." I built both behaviors correctly without even meaning to. That distinction is going straight into my mental model.

Gotcha #4: My list endpoint gave a "cannot fetch" until I noticed I'd dropped the leading / in the route path. Added the slash, instantly worked. The kind of bug that's invisible for ten minutes and obvious the second you spot it.

Step 5: PATCH — change only what changed

Update has two flavors, and picking the right one matters:

PUT = "replace the whole resource." The client must resend every field; anything left out gets wiped.
PATCH = "apply a partial change." Send only the fields you're changing; everything else stays.

For fixing a typo in one expense, forcing the user to resend amount + description + date [PUT's demand] is clumsy. So I built PATCH. It needs its own schema where every field is optional:

class ExpenseUpdate(BaseModel):
    amount: Decimal | None = Field(default=None, gt=0)
    description: str | None = Field(default=None, min_length=1, max_length=255)
    spent_on: date | None = None

@app.patch("/expenses/{expense_id}", response_model=ExpenseRead)
def update_expense(expense_id: int, payload: ExpenseUpdate, db: Session = Depends(get_db)):
    expense = db.get(Expense, expense_id)
    if expense is None:
        raise HTTPException(status_code=404, detail="Expense not found")

    update_data = payload.model_dump(exclude_unset=True)
    for field, value in update_data.items():
        setattr(expense, field, value)

    db.commit()
    db.refresh(expense)
    return expense

X | None = None makes a field optional — "either a Decimal or nothing." [Older tutorials write Optional[Decimal]; same meaning, | None is the modern style.] Note the validation still rides along: if amount is sent, it must still be > 0.
model_dump(exclude_unset=True) is the heart of PATCH — it gives me a dict of only the fields the client actually sent, ignoring the untouched ones. Without it, an omitted field would come through as None and I'd accidentally erase existing data. This one flag avoids the whole trap.
setattr(expense, field, value) sets an attribute by a name held in a variable — the dynamic version of expense.amount = .... Since I don't know in advance which fields arrived, I loop and set each one.

Gotcha #5: Two things bit me here. First, another 500, because I typed details= instead of detail= in HTTPException — a bad keyword makes the exception itself blow up. Second, and sneakier: when I hit Execute in /docs without editing the body, my amount came back as some huge float. Turns out Swagger pre-fills the request body with placeholder sample values — clicking Execute doesn't send "nothing," it sends those placeholders. So PATCH dutifully saved a giant number. [Combined with SQLite storing Numeric as float, it looked even uglier — that tidies up on Postgres later.] Lesson: to test a partial update, edit the body down to just the field you mean, e.g. {"amount": 99.99}. exclude_unset can't exclude what Swagger auto-filled for you.

Step 6: DELETE — remove one, return nothing

Last verb, and it introduces one more status code:

@app.delete("/expenses/{expense_id}", status_code=status.HTTP_204_NO_CONTENT)
def delete_expense(expense_id: int, db: Session = Depends(get_db)):
    expense = db.get(Expense, expense_id)
    if expense is None:
        raise HTTPException(status_code=404, detail="Expense not found")
    db.delete(expense)
    db.commit()
    return None

204 No Content is the convention for a successful delete: "it worked, and there's deliberately nothing to send back." That's why this endpoint has no response_model — there's no resource left to shape.
db.delete() + db.commit() is the destructive bit. Once committed, the row is gone — no undo. So I tested it on a throwaway expense, deleted it [204], then GET-ed the same id to confirm it returned a clean 404. Gone means gone.

One non-code head-scratcher [worth writing down]

At one point 127.0.0.1:8000/docs took ages to load and I assumed my code was broken. It wasn't. /docs is Swagger UI, and by default FastAPI tells your browser to download Swagger's JS/CSS from a public CDN — which crawls on a slow or corporate/proxied network. My actual API was instant [hitting /expenses directly proved it]. Nice reminder: a slow docs page is not a slow app. [The production fix is self-hosting those assets, but that's polish for a later hardening phase.]

Stuff I want to remember [the honest takeaways]

One model for input, a different one for output. Never accept or expose fields you shouldn't.
Every required DB column must appear in your input schema — check the model up front instead of playing 500-error whack-a-mole.
Status codes carry meaning: 201 create, 200 read/update, 204 delete, 404 missing resource, 422 malformed request.
422 vs 404 is a real distinction: bad shape vs valid-but-absent.
raise HTTPException(...) [not return] is how you send an error and stop.
model_dump() is one method with an underscore. model_dump(exclude_unset=True) is what makes PATCH safe.
Write your DB-session logic once as a Depends dependency with yield/finally — never leak a connection.
Money stays Decimal all the way to the API edge.
db.delete() + commit() is permanent. Test destructive stuff on junk data.
Swagger pre-fills placeholder values — a blind "Execute" can overwrite real data.
When you cut a corner [like hardcoding the owner], write it down and leave yourself the one-line path back.

Next up: Phase 3, Authentication — where that hardcoded DEV_USER_ID finally retires. The app has a memory and a mouth; now it needs a lock on the door: registration, hashed passwords, JWT logins, and making sure no user can peek at another's expenses. If Phase 2 gave the app a mouth, Phase 3 gives it a bouncer. See you there.

My App Can Finally Remember Stuff! (Phase 1 — The Database)

Azhar Alvi — Wed, 22 Jul 2026 09:23:28 +0000

Design it on paper, model it in Python, and NEVER touch the schema by hand.

So Phase 0 got my little FastAPI app running. One route, one JSON response, a lot of pride. But here's the thing nobody warns you about: that app had the memory of a goldfish. Restart it and… nothing. No users, no data, no clue who anyone is.

Phase 1 fixes that. This is where the app gets an actual database — a place to remember things. And honestly? This is where "I'm following a tutorial" started turning into "oh, I kind of get how backends work now." I went in knowing zero SQL. Came out having designed tables, built models, run a real migration, and read/written actual data. Let me dump what I learned [and the parts that tripped me up, because there were a few].

The Structure is as follows. Lets call it PHASE 1 — The Data Layer:

Get the right tools installed in the right place (SQLAlchemy + Alembic)
Design the tables on paper BEFORE writing any code
Turn that design into Python models
Wire up the database connection
Set up Alembic and run my first migration
Actually write and read a row [the payoff!]

First, the two new toys

Two libraries do the heavy lifting here:

SQLAlchemy — the ORM. Fancy word, simple job: it lets me talk to the database in Python instead of writing raw SQL. I write session.add(user), it writes the INSERT for me.
Alembic — the migration tool. Think of it as git, but for the shape of your database. Every time I change the table structure, it saves that change as a numbered file I can replay or roll back.

source venv/Scripts/activate      # Windows/Git Bash = Scripts/, not bin/ [learned this the hard way in Phase 0]
pip install sqlalchemy alembic
pip freeze > requirements.txt

Gotcha #1: I first installed these in a random throwaway folder, then wondered why my real project couldn't see them. Turns out a virtual environment is per-folder — packages installed in one venv are invisible to another. Reinstalled in the actual project. Lesson: check for (venv) in your prompt and make sure it's the right one before you install anything.

Step 1: Draw it on paper (yes, really)

Before touching code, I sketched two boxes:

USERS                              EXPENSES
  id       (primary key)             id         (primary key)
  name                               amount     (money)
  email    (unique)                  description
  created_at / updated_at            spent_on   (the date)
                                     user_id  --> points to USERS.id
                                     created_at / updated_at

The two ideas that made everything click:

A primary key (id) is just a unique, auto-numbered tag for each row. Names repeat, IDs don't.
A foreign key (user_id) is a column that stores another table's id. That's the whole magic of relational databases — Azhar's expenses all carry his user_id, so the DB always knows whose lunch was whose.

Sounds obvious now. Was NOT obvious an hour earlier.

Step 2: Turn the drawing into models

This is models.py — basically my paper sketch, but in Python. One class = one table.

from datetime import date, datetime
from decimal import Decimal

from sqlalchemy import MetaData, String, DateTime, Numeric, Date, ForeignKey, func
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column, relationship


NAMING_CONVENTION = {
    "ix": "ix_%(column_0_label)s",
    "uq": "uq_%(table_name)s_%(column_0_name)s",
    "ck": "ck_%(table_name)s_%(constraint_name)s",
    "fk": "fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s",
    "pk": "pk_%(table_name)s",
}


class Base(DeclarativeBase):
    metadata = MetaData(naming_convention=NAMING_CONVENTION)


class User(Base):
    __tablename__ = "users"

    id: Mapped[int] = mapped_column(primary_key=True)
    name: Mapped[str] = mapped_column(String(100))
    email: Mapped[str] = mapped_column(String(255), unique=True, index=True)
    created_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), server_default=func.now())
    updated_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), server_default=func.now(), onupdate=func.now())
    expenses: Mapped[list["Expense"]] = relationship(back_populates="user")


class Expense(Base):
    __tablename__ = "expenses"

    id: Mapped[int] = mapped_column(primary_key=True)
    amount: Mapped[Decimal] = mapped_column(Numeric(10, 2))
    description: Mapped[str] = mapped_column(String(255))
    spent_on: Mapped[date] = mapped_column(Date)
    user_id: Mapped[int] = mapped_column(ForeignKey("users.id"), index=True)
    created_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), server_default=func.now())
    updated_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), server_default=func.now(), onupdate=func.now())
    user: Mapped["User"] = relationship(back_populates="expenses")

A few things I picked up here that felt like "real developer" moments:

Money is NEVER a float. Ever. Floats can't hold 0.10 + 0.20 exactly [it comes out as 0.30000000000000004, I'm not kidding], so over enough expenses your totals drift. Store it as Numeric(10, 2) → Python Decimal. Exact, always.
Every table gets created_at and updated_at. You will always, always want to know when something was made or changed.
The type annotation controls nullability. Mapped[str] = required. Mapped[str | None] = optional. Neat.
Those two relationship(...) lines aren't columns — they're just Python convenience so I can write user.expenses and get a list back without writing a query. The actual link is still the user_id foreign key.

Gotcha #2: I originally named the expense date column date. Bad idea — naming a column the same as its Python type (date: Mapped[date]) confuses everything and breaks type inference. Renamed it spent_on. Moral: don't name your stuff after builtins.

Step 3: The connection [kept separate on purpose]

database.py — this is how to connect, deliberately kept apart from models.py [which is what the tables are]:

import os
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

DATABASE_URL = os.getenv("DATABASE_URL", "sqlite:///./expenses.db")
connect_args = {"check_same_thread": False} if DATABASE_URL.startswith("sqlite") else {}

engine = create_engine(DATABASE_URL, echo=True, connect_args=connect_args)
SessionLocal = sessionmaker(bind=engine, autoflush=False, autocommit=False)

Why the os.getenv dance instead of just hardcoding the path? Because future-me deploying to a real Postgres database will just set an environment variable and NOT have to change a single line of code. Same reason secrets live in .env. One source of truth. Also — echo=True prints every SQL statement the ORM generates, which is weirdly satisfying to watch.

Oh, and before creating any of this I added *.db and *.sqlite3 to .gitignore. The database file is local junk data — it has no business in my repo. [And yeah, same "before it exists" trick I used for .env — git can't accidentally track what it was already told to ignore.]

Step 4: Alembic and my first migration

Here's the part I was low-key scared of, and it turned out to be the coolest bit.

alembic init alembic     # creates the migration setup

Then I pointed Alembic at my project in alembic/env.py — told it where my models live and where the database is:

from database import DATABASE_URL
from models import Base

config.set_main_option("sqlalchemy.url", DATABASE_URL)
target_metadata = Base.metadata

This is the important bit: Alembic's autogenerate works by comparing my models to the actual database and writing the difference. target_metadata is how it "sees" my models. Without it, it detects nothing.

I also added that NAMING_CONVENTION thing (up in models.py) BEFORE generating anything. Why bother? Because otherwise the database invents random names for your constraints/indexes — and SQLite often gives them no name at all. Then a future migration that needs to change one has nothing to grab onto. Set the convention early, and everything gets clean, predictable names like fk_expenses_user_id_users. Set-it-and-forget-it.

Then the magic command:

alembic revision --autogenerate -m "create users and expenses tables"

And it wrote the migration for me — two create_table calls, the foreign key, the indexes, plus a matching downgrade() that undoes it all. I read the whole file before running it [apparently this is a habit real teams enforce — autogenerate isn't perfect, so you always eyeball it first]. Looked right. So:

alembic upgrade head     # actually builds the tables
alembic current          # shows my revision with (head) = up to date

Watching the real CREATE TABLE SQL scroll past because of echo=True? Chef's kiss. That was the "oh, THIS is what an ORM does" moment.

Gotcha #3: My -m message accidentally said "expense" (singular), so the migration filename said expense too — and I panicked thinking the tables were wrong. They weren't. The -m text is just a label; the real table names come from __tablename__. Totally cosmetic.

Gotcha #4: When I pasted my code into an email, Gmail helpfully turned users.id into a clickable link http://users.id/. Nearly gave me a heart attack. It's just email being email — the real file was fine. Check your code in the editor, not in email.

Step 5: The payoff — write a row, read it back

from decimal import Decimal
from datetime import date
from sqlalchemy import select
from database import SessionLocal
from models import User, Expense

with SessionLocal() as session:
    user = User(name="Azhar", email="azhar@example.com")
    session.add(user)
    session.commit()            # NOW it's in the DB, and user.id gets assigned

    session.add(Expense(
        amount=Decimal("12.50"), description="Lunch",
        spent_on=date.today(), user_id=user.id,
    ))
    session.commit()

    fetched = session.scalars(select(User)).first()
    print(fetched.id, fetched.name, [(e.description, e.amount) for e in fetched.expenses])

And it printed my user and their lunch. My app remembers things now. 🎉

Couple of things worth knowing:

Nothing actually hits the database until commit(). That's also when the primary key gets assigned — which is exactly why I commit the user before the expense that needs its id.
Decimal("12.50") uses quotes on purpose. Decimal(12.50) [no quotes] would drag the float imprecision back in. Little detail, big deal for money.
select(User) with session.scalars(...) is the modern SQLAlchemy 2.0 way. If you see session.query(...) in older tutorials, that's the legacy style.

Gotcha #5: Ran the script a second time and it blew up with an IntegrityError on the email. That's not a bug — it's my unique constraint literally doing its job and refusing a duplicate. Honestly kind of reassuring to see it work.

Stuff I want to remember [the honest takeaways]

Design on paper first. The code is just the drawing, translated.
Money is Decimal/Numeric, never float. Build it from a string.
Give every table created_at / updated_at.
Never hardcode the database URL — read it from an env var.
NEVER edit the database structure by hand. Models → migration, every single time.
Always read an autogenerated migration before you run it.
Set your naming convention before the first migration, not after.
Virtual environments are per-project. Install in the right one. Freeze requirements.txt after every install.
Ignore .db files and secrets before they exist. And always commit your migration files — they're the schema's shared history.
Keep echo=True on while learning so you can actually see the SQL. It demystifies everything.

Next up: Phase 2, where I turn all this into real API endpoints [POST an expense, GET the list, the whole CRUD gang]. If Phase 1 gave the app a memory, Phase 2 gives it a mouth. See you there.

Phase 0 : Building My First FastAPI App: Setup, Git, and Secrets Done Right

Azhar Alvi — Thu, 16 Jul 2026 18:57:38 +0000

Tagline: Commit small, commit often, write real messages.

Creating a hello-world app sounds easy — and it is. But doing it the right way, with proper git hygiene, isolated environments, and secrets handled safely from day one? That takes a bit more care. Here's what I actually did, step by step, and why.

Index

Introduction
Structure of this log
Step 1: Project Foundations
- Create the folder
- Initialize git first
- Create .gitignore before installing anything
- Create and activate the virtual environment
- Install packages + freeze requirements
- First commit
- Connect to GitHub
- The repeatable loop
- The commit flow, in isolation
Step 2: Getting FastAPI Running Locally
- Ensure the virtual environment is active
- Install FastAPI and Uvicorn
- Create the app file
- Start the server
- Check the automatic docs
Step 3: Secrets — the .env File
- Create .env
- Confirm it's actually ignored
Step 4: Start This Build Log
Key Habits to Keep

Introduction

I started learning backend dev properly this week, and today I got a hello-world FastAPI app running locally. Nothing fancy — one route, one JSON response — but I wanted to write down what actually happened along the way, because "install a package and run a command" always looks simpler in hindsight than it feels in the moment.

Structure of this log

Create project folder → init git → .gitignore → virtual environment
Connect to a GitHub repo
Build and run a FastAPI hello-world app, explore /docs
Set up a .env file for secrets and confirm it's gitignored
Start this build log

Step 1: Project Foundations

Create the folder

mkdir my-project-1
cd my-project-1

Initialize git first

git init

Why first? So every file created from this point on is tracked from day one — no risk of forgetting to init later.

Create `.gitignore` before installing anything

cat > .gitignore << 'EOF'
venv/
__pycache__/
.env
.DS_Store
EOF

Why before the virtual environment? If you create the venv first, git could briefly see hundreds of library files before you've excluded them. Doing this first avoids ever accidentally staging things you don't want tracked.

How this command works:

cat — normally reads and displays file content, but here it's not reading a file — it's about to receive typed input instead.
> — redirect operator. Instead of printing to the screen, the output is written into a file. Since .gitignore doesn't exist yet, this creates it.
<< 'EOF' — a heredoc. It tells bash: "don't wait for a real file — treat everything typed next, up until a line that says exactly EOF, as the input text."
EOF (closing) — signals "stop, that's the end of the input."

Note: EOF isn't a special keyword — it's just a convention. You could use BANANA instead, and it would work identically: bash treats everything as raw text until it sees a line containing exactly that word. EOF ("End Of File") is used everywhere because it instantly signals intent to anyone reading the script.

Note: This heredoc syntax is bash-specific. PowerShell uses a different syntax (@" ... "@ | Out-File) — match the syntax to the shell you're actually in.

Create and activate the virtual environment

python -m venv venv
source venv/Scripts/activate

What this does:

python -m venv venv — runs Python's built-in venv module, creating a folder (venv/) containing an isolated copy of Python and its own package directory.
source venv/Scripts/activate — activates it, redirecting your terminal's python/pip to point inside venv/ instead of your system-wide install. You'll know it worked when (venv) appears in your prompt.

Note: The folder is named Scripts/ on Windows and bin/ on Linux/macOS. If source venv/bin/activate fails with "No such file or directory," check which one actually exists with ls venv.

Install packages + freeze requirements

pip install requests
pip freeze > requirements.txt

Why this matters: every time you install something new, freeze it into requirements.txt. This makes the exact dependency set shareable — anyone (including future-you) can recreate your environment with pip install -r requirements.txt.

First commit

touch README.md main.py      # or: New-Item README.md, main.py   (PowerShell)
git add .
git commit -m "Initial project setup"

What makes a good commit message: it describes what changed and why — not just "update" or "fix stuff."

Connect to GitHub

Create a new, empty repository on GitHub first, then:

git remote add origin <your-repo-url>
git branch -M main
git push -u origin main

Breaking this down:

Command	What it does
`git remote add origin <url>`	Registers a remote connection, nicknamed `origin` (convention), pointing at your GitHub repo's URL. No data moves yet — this just registers the address.
`git branch -M main`	Renames your current branch to `main` (forcing it even if a branch with that name exists), matching what GitHub expects by default.
`git push -u origin main`	Uploads your commits to GitHub for the first time. `-u` sets up tracking between local `main` and `origin/main`, so every push after this can just be `git push`.

Run this sequence once per project — right at the start, connecting a fresh local repo to a fresh GitHub repo.

The repeatable loop (used for every session after this)

source venv/Scripts/activate
# ... work, install packages ...
pip freeze > requirements.txt
git add .
git commit -m "clear description of change"
git push
deactivate

The commit flow, in isolation

git status                          # check what changed
git add .gitignore                  # stage the change
git commit -m "clear description"   # commit with a real message
git push                            # push to GitHub
git log --oneline -1                # sanity check

Step 2: Getting FastAPI Running Locally

Ensure the virtual environment is active

source venv/Scripts/activate

Install FastAPI and Uvicorn

pip install fastapi uvicorn
pip freeze > requirements.txt

FastAPI — lets you define API routes/endpoints in Python. It doesn't serve requests on its own — it needs an ASGI (Asynchronous Server Gateway Interface) server to actually run.
Uvicorn — a lightweight ASGI server that runs your app and listens for HTTP requests.

Create the app file

code .   # opens the current folder in VS Code

Structure of main.py:

Import FastAPI
Create an application instance (app = FastAPI()) for Uvicorn to run
Use a decorator (@app.get("/")) so that a GET request to the root URL runs the function below it
Define the function to handle the request
Return the response (FastAPI auto-converts a Python dict to JSON)

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, World!"}

Start the server

uvicorn main:app --reload

main:app — tells Uvicorn to look inside main.py for an object named app.
--reload — automatically restarts the server whenever you save a code change.

Visit http://127.0.0.1:8000 to see the JSON response.

Check the automatic docs

Visit http://127.0.0.1:8000/docs — FastAPI auto-generates a full interactive API explorer (Swagger UI / OpenAPI spec), built entirely from your route definitions. No docs code required.

A read-only alternative view is available at /redoc.

Step 3: Secrets — the `.env` File

Create `.env`

cat > .env << 'EOF'
APP_SECRET=super-secret-value-123
EOF

Confirm it's actually ignored — don't just assume

git status                 # .env should not appear anywhere in the output
git check-ignore -v .env   # the definitive test

git check-ignore -v reports exactly which line in which file is causing the file to be ignored, e.g.:

.gitignore:7:.env    .env

Important: .gitignore only prevents git from tracking files it hasn't already started tracking. If a secret was committed before being added to .gitignore, it will still exist in your git history. Setting up the ignore rule before the first git add — which is what happened here — avoids this entirely.

Step 4: Start This Build Log

Keep two documents, for two different audiences:

BUILD_LOG.md (this file) — chronological, for future-me. What I did, what broke, what I learned. Terse is fine.
README.md — for other people (or future-me pretending to be someone else). What the project is and how to run it — a snapshot of current state, not a diary.

The most useful log entries capture the why, not just the what — especially for snags:

## 2026-07-16

- Set up project folder, git repo, and Python virtual environment
- Installed FastAPI + Uvicorn, built a hello-world app with a single GET / route
- Confirmed it runs locally and explored the auto-generated /docs (Swagger UI)
- Set up a .env file for secrets and confirmed it's properly gitignored
  (learned: .gitignore only blocks files git hasn't tracked yet — order matters)

Commit it the same way as everything else:

git add BUILD_LOG.md
git commit -m "Start build log with first entry"
git push

Key Habits to Keep

Commit small, commit often, write real messages — a message should answer "what changed and why," not just "update."
.gitignore before git add, always — order of operations is what actually protects secrets.
Freeze requirements on every install, not just at the end.
Log the "why" and the snags, not just the "what" — that's the part future-you will actually forget.

DEV Community: Azhar Alvi

Phase 4 [Part 2] : The Deviation

A second confession: I pulled two Phase-5 jobs forward [and picked up a third I didn't plan]

Debt #1: the 30-minute dead-end [expired-token hardening]

The cleanup I didn't plan on: props [the refactor]

Debt #2: it looked like a 1998 government form [Tailwind]

The shape of every React conversation [the model that tied it together]

Stuff I want to remember [the honest takeaways]

PHASE 4 — The Face

A confession before we start: I changed the plan

First, the new world [everything here is different from the backend]

Step 1: My first component [JSX has three rules that bite]

Step 2: A login form that holds its own text [useState]

Step 3: Call the backend — and get mugged by CORS

Step 4: Store the token [the one real security decision this phase]

Step 5: The expense list [useEffect, and the infinite-loop trap]

Step 6: The three gaps nobody builds [loading, empty, error]

Step 7: Full CRUD from the UI [add, delete, edit]

Step 8: The bug that made login "do nothing until I refreshed"

Bonus: so how does clicking "Save" actually change the database?

Stuff I want to remember [the honest takeaways]

Teaching My Backend to Lock the Door — FastAPI Auth, Phase 3

First, the new ideas [and yes, this time there IS stuff to install]

Step 1: Give users a place to store a password [a hashed one]

Step 2: The hashing helpers [hashing is NOT encryption]

Step 3: POST /auth/register [where the hash finally gets used]

Step 4: What a JWT actually is [read this before you trust one]

Step 5: POST /auth/login [check the password, hand back a token]

Step 6: get_current_user [the gatekeeper]

Step 7: Lock the endpoints and scope them to the owner [the boss fight]

Step 8: Prove it [the part tutorials skip]

Stuff I want to remember [the honest takeaways]

Teaching My Backend to Listen and Reply — FastAPI CRUD, Phase 2

First, the two new ideas [and no, nothing to install this time]

Step 1: Two contracts — one for input, one for output

A quick detour: who owns this expense?

Step 2: The session dependency [write it once, never leak a connection]

Step 3: POST — create an expense [it all comes together]

Step 4: GET — list them all, and fetch one [meet the 404]

Step 5: PATCH — change only what changed

Step 6: DELETE — remove one, return nothing

One non-code head-scratcher [worth writing down]

Stuff I want to remember [the honest takeaways]

My App Can Finally Remember Stuff! (Phase 1 — The Database)

First, the two new toys

Step 1: Draw it on paper (yes, really)

Step 2: Turn the drawing into models

Step 3: The connection [kept separate on purpose]

Step 4: Alembic and my first migration

Step 5: The payoff — write a row, read it back

Stuff I want to remember [the honest takeaways]

Phase 0 : Building My First FastAPI App: Setup, Git, and Secrets Done Right

Index

Introduction

Structure of this log

Step 1: Project Foundations

Create the folder

Initialize git first

Create .gitignore before installing anything

Create and activate the virtual environment

Install packages + freeze requirements

First commit

Connect to GitHub

The repeatable loop (used for every session after this)

The commit flow, in isolation

Step 2: Getting FastAPI Running Locally

Ensure the virtual environment is active

Install FastAPI and Uvicorn

Create the app file

Start the server

Check the automatic docs

Step 3: Secrets — the .env File

Create .env

Confirm it's actually ignored — don't just assume

Step 4: Start This Build Log

Key Habits to Keep

Create `.gitignore` before installing anything

Step 3: Secrets — the `.env` File

Create `.env`