DEV Community: Mafy Hidalgo

From Local Storage to a Real Backend: How I Built the RollbackHQ API

Mafy Hidalgo — Mon, 10 Aug 2026 10:03:21 +0000

Part two of building RollbackHQ. In part one I built the React frontend with mock data in the browser. This time I gave it a real brain: a Node/Express + MongoDB backend with authentication, a safety pipeline, and analytics. Built for Uplift Code Camp, Project 5.

The problem with my first version

My P4 app, RollbackHQ, was a safety layer that catches bad AI-driven changes to a database before they're committed. It worked but it faked everything. The "database" was the browser's Local Storage, and the safety rules ran client-side. Clear the browser and your data was gone. Anyone could open DevTools and bypass the rules.

For P5, I moved the whole thing to where it belongs: a real server. The guiding principle became clients propose, the server decides. The frontend can only ask; the backend owns the truth.

The stack

Node.js + Express for the API
MongoDB (Atlas) with Mongoose for the database
Bcrypt + JWT for authentication
helmet, cors, dotenv for security and config

Lesson 1: passwords you can't read

The first thing I built was authentication, and the most important idea was that you never store a real password. You store a Bcrypt hash, a one-way scramble.

// register
const passwordHash = await bcrypt.hash(password, 10);
await User.create({ email, passwordHash });

// login
const isMatch = await bcrypt.compare(password, user.passwordHash);

Hashing is one-way, like blending a smoothie, you can't un-blend it. At login you hash the typed password and compare hashes; you never need the original back. When I looked at my own database, the password field was pure gibberish like $2b$10$N9qo8.... Even I can't read it. That's the point.

Then, on successful login, the server hands out a JWT - a signed token that proves who you are on every future request:

const generateToken = (userId) =>
  jwt.sign({ id: userId }, process.env.JWT_SECRET, { expiresIn: "7d" });

Lesson 2: the auth gate (middleware)

Every route except register and login is protected by one small function that runs before the route:

export const protect = async (req, res, next) => {
  const token = req.headers.authorization?.split(" ")[1];
  if (!token) return res.status(401).json({ message: "Not authorized, no token" });
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  req.user = await User.findById(decoded.id).select("-passwordHash");
  next(); // passed the check -> continue to the route
};

Middleware was a new concept for me: it's a checkpoint that either calls next() to continue, or stops the request with a 401. And req.user is the magic part once the gate identifies the user, every decision downstream can be attributed to them.

Lesson 3: the safety pipeline (the heart of it)

When an AI change comes in, the server does three things in order and crucially, it does not touch the record:

// 1. Snapshot the current value FIRST
await Snapshot.create({ recordId, value: record.value, label: "auto-captured" });

// 2. Validate against a configurable threshold
const { status, reason } = evaluateChange(record.value, newValue, threshold);

// 3. Store the change as pending or flagged. Record is untouched.
await Change.create({ recordId, oldValue: record.value, newValue, status, reason });

The rule engine is a pure function I ported straight from my P4 frontend, no database, no Express, just logic. That made it easy to move server-side. A change beyond the threshold gets flagged automatically; a normal one waits as pending. Either way, the actual data doesn't change until a human approves.

Lesson 4: one request, three entities

This was the big architectural shift from P4. In the frontend version, approving a change meant the browser updated three things itself. On a real backend, that's fragile and insecure. So now the frontend sends one request, and the server does all three updates:

// PATCH /api/changes/:id  { decision: "approve" }
record.value = change.newValue;        // 1. update the record
await record.save();
change.status = "approved";            // 2. flip the change
change.decidedBy = req.user._id;       //    ...attributed to the user
await AuditEntry.create({              // 3. write the audit log
  recordId, userId: req.user._id, action: "approved"
});

One call, three entities, all attributed. And a guard stops you from deciding the same change twice (409 Conflict). The frontend just displays whatever the server returns.

Lesson 5: analytics with MongoDB aggregations

For the reporting requirement I built an "AI Trust Report", how often the AI produces risky changes. Instead of pulling everything into Node and counting, I let MongoDB do it:

const byStatus = await Change.aggregate([
  { $group: { _id: "$status", count: { $sum: 1 } } },
]);

$group buckets documents and counts them, like SQL's GROUP BY, but in Mongo. The endpoint returns a flag rate, a status breakdown, and the most-corrected records. It's a genuine analytics feature, not a checkbox.

Deploying: the Atlas whitelist gotcha

I deployed the API to Render and immediately got a 502. The logs told the real story:

MongoDB connection failed: Could not connect... make sure your
current IP is on your Atlas cluster's IP whitelist

Render's servers weren't allowed to reach my database. The fix was setting Atlas Network Access to allow all IPs (0.0.0.0/0), fine for a student project. The other lesson: on a host, you don't hardcode a port. process.env.PORT lets Render assign its own, which is exactly why the app said "Server running on :10000" in the logs.

Connecting the two halves

The final step was pointing my deployed React frontend at the live API. I added a small API service layer that attaches the JWT to every request:

async function request(path, options = {}) {
  const res = await fetch(`${BASE_URL}${path}`, {
    ...options,
    headers: {
      "Content-Type": "application/json",
      ...(getToken() ? { Authorization: `Bearer ${getToken()}` } : {}),
    },
  });
  if (!res.ok) throw new Error((await res.json()).message);
  return res.json();
}

Now the whole thing runs on the public internet: React on Netlify → Express on Render → MongoDB Atlas. Login, create a record, watch the server catch a bad AI change, approve it, see the analytics, all with real, persisted data.

What I learned

Clients propose, the server decides. Anything the frontend can do, a user can do, so the rules and the writes have to live on the server.
Middleware is just a checkpoint. Auth is one function that runs before your routes and either lets the request through or blocks it.
Read the deploy logs. My 502 wasn't mysterious, the logs named the exact problem (Atlas whitelist) in plain English.
Pure functions travel well. Because my rule engine had no dependencies, moving it from the browser to the server was almost copy-paste.

The AI is still simulated, the frontend proposes the changes. The next step is a real AI integration behind the API, plus email alerts when an anomaly is flagged and role-based permissions. Same product, growing up.

Try it: https://rollbackhq.netlify.app/live log in, create a record, and hit "Simulate Faulty AI" to watch the server catch a bad change.

How I Built RollbackHQ: An "Undo Button" for AI... My First Real React App

Mafy Hidalgo — Mon, 06 Jul 2026 07:27:21 +0000

The idea: what happens when an AI silently changes your numbers?

Companies are starting to let AI systems read and write their business data like forecasts, inventory counts, financial figures. But what happens when the AI hallucinates?

Imagine an inventory AI that misreads a data glitch and changes a reorder quantity from 44 boxes to 4,400. Nobody notices. The company orders millions of pesos of stock nobody needs - and the original number is gone forever, because the AI overwrote it.

That's the problem RollbackHQ solves.

It's a safety dashboard that sits between an AI and the database. Before any AI-driven change is committed:

📸 It snapshots the original value
🛡️ It validates the new value against safety rules (changes beyond a % threshold get auto-flagged)
👤 It routes changes to a human for approval
↩️ And if something bad slips through — one-click rollback to any known-good version

I call it "undo for your AI."

The Stack

React + Vite — the app itself
Redux Toolkit — centralized state (five slices: records, changes, snapshots, audit log, settings)
React Router — five pages: Dashboard, Snapshots, AI Changes, History, Settings
Local Storage — persistence across reloads
Cypress — end-to-end tests (which caught a real bug — more on that later!)
Plain CSS, responsive down to phone widths

The MVP simulates the AI source and the database in the browser, per my project proposal - the production version would run as middleware with a real backend, which is my plan for the next projects.

Step 1: Design the data model BEFORE writing components

The best advice I got: figure out what your data looks like first, and the components almost write themselves. RollbackHQ has four kinds of data, connected by recordId like a foreign key:

// A record — a business figure we're protecting
{ id: "REC-2041", name: "Q3 Sales Forecast", field: "amount", value: 1200 }

// An AI change — a PROPOSAL, not a write
{
  id: "CHG-002",
  recordId: "REC-1180",
  oldValue: 44,
  newValue: 4400,
  status: "flagged",   // pending | flagged | approved | rejected
  reason: "Change exceeds 500% threshold - likely AI error",
}

// A snapshot — the "before photo", captured automatically
{ id: "SNAP-003", recordId: "REC-1180", version: 1, value: 44, label: "initial" }

// An audit entry — every decision leaves a trace
{ id: "AUD-001", recordId: "REC-2041", action: "approved", detail: "amount: 1200 → 1260" }

The single most important rule in the whole app: a pending or flagged change has ZERO effect on the record. Only a human clicking Approve writes to the data. The AI doesn't get to write — it only gets to propose.

Step 2: Redux Toolkit — the app's brain

Every page needs to see the same data, so all application state lives in one Redux store with a slice per data type. Here's the records slice:

import { createSlice } from "@reduxjs/toolkit";
import { initialRecords } from "../data/mockData";

const recordsSlice = createSlice({
  name: "records",
  initialState: initialRecords,
  reducers: {
    // Used by both Approve and Rollback
    updateRecordValue: (state, action) => {
      const { recordId, newValue } = action.payload;
      const record = state.find((r) => r.id === recordId);
      if (record) {
        record.value = newValue;
      }
    },
  },
});

(Fun fact I learned: mutating state like this is normally forbidden in React, but Redux Toolkit uses Immer under the hood, which secretly builds an immutable copy. It looks like mutation but isn't.)

The payoff came when I built the review screen. Approving a change dispatches three actions - update the record, flip the change status, write an audit entry:

const handleApprove = (change) => {
  // 1. Commit the new value to the record
  dispatch(updateRecordValue({ recordId: change.recordId, newValue: change.newValue }));
  // 2. Mark the change as approved
  dispatch(setChangeStatus({ changeId: change.id, status: "approved" }));
  // 3. Leave a trace in the audit log
  dispatch(addAuditEntry({
    id: `AUD-${Date.now()}`,
    recordId: change.recordId,
    action: "approved",
    detail: `${change.field}: ${change.oldValue} → ${change.newValue}`,
    timestamp: new Date().toISOString(),
  }));
};

...and the Dashboard's "Pending Approval" counter on a completely different page updates instantly, because both pages read the same store. No message passing. That was the moment Redux clicked for me.

Step 3: The rule engine — catching the AI's mistakes

The validation logic lives in a pure function, separate from the UI. It simulates an AI proposing changes — usually small sensible tweaks, but 30% of the time a wild error (10x–100x the real value), because that's what makes the demo interesting:

// 30% chance of a faulty AI output
const isCrazy = Math.random() < 0.3;
let newValue;
if (isCrazy) {
  newValue = record.value * (10 + Math.floor(Math.random() * 90)); // 10x-100x
} else {
  const tweak = 1 + (Math.random() * 0.2 - 0.1); // -10% to +10%
  newValue = Math.round(record.value * tweak);
}

// Rule check: percent change vs the configurable threshold
const percent = Math.abs(((newValue - record.value) / record.value) * 100);
const isFlagged = percent > thresholdPercent;

Crucially, the snapshot of the current value is captured BEFORE the proposal is even evaluated. Protect first, then consider.

Step 4: Persistence in ~20 lines

One of my graded specs was Local Storage. The elegant part: because ALL state lives in Redux, persistence is one subscription on the store — no component changes at all:

// After every dispatch, save the whole state
store.subscribe(() => {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(store.getState()));
});

// On startup, load it back (or fall back to mock data)
const loadState = () => {
  const saved = localStorage.getItem(STORAGE_KEY);
  if (saved === null) return undefined; // undefined = use initial state
  return JSON.parse(saved);
};

Simulate some changes, approve a few, refresh the page, everything survives.

The bug my own tests caught (my favorite part)

For bonus points I added Cypress end-to-end tests - scripts that open a real browser and click through the app like a user. I wrote five tests: dashboard renders, navigation works, simulating adds a change, approving updates the record, and state persists across reloads.

Four passed. One went red.

(uncaught exception) ReferenceError: addAuditEntry is not defined
  at handleSimulate (src/pages/Dashboard.jsx)

Here's the thing: I had manually tested this feature and it "worked." But the crash only happened when a simulated change got FLAGGED which is a 30% random chance. My manual clicks had gotten lucky rolls. The robot clicked once, hit a flagged change, and exposed a missing import I'd forgotten when adding the flag-to-audit-log feature.

The fix was one line. The lesson was bigger: testing shows the presence of bugs, never their absence - but automated tests catch what lucky manual testing walks right past. The bug had even made it into my deployed site. One-line fix, rebuild, redeploy, 5/5 green.

Deploying

npm run build produces an optimized dist folder, and Netlify's drag-and-drop deploy puts it on the public internet in about 20 seconds. One gotcha worth knowing for any React Router app: you need a _redirects file telling the server to serve index.html for every path — otherwise refreshing on /snapshots gives a 404, because the routes only exist in the browser:

/*    /index.html   200

What I learned

Design the data model first. Every screen was easier because the state shape was right.
Store the minimum, compute the rest. The KPI numbers aren't stored anywhere — they're derived from the changes array on every render, so they can never go stale.
Read the error, not just the suggestion. Vite once told me to "try inserting a semicolon" when the actual bug was cconst — a typo. The quoted code in an error message is more truthful than the parser's guess.
Terminal commands and file contents are different things. Ask me how I know. 😅

What's next

This won't stay an MVP. My plan for the upcoming backend and full-stack projects is to grow RollbackHQ into the real thing: a Node/Express API with JWT authentication and user roles, the rule engine running server-side with email alerts when anomalies are detected, and a real AI integration replacing the simulator. Same product, three projects, one story.

> Mafy Hidalgo is a full-stack web development student at Uplift Code Camp (FSWBATCH29). RollbackHQ is her Project 4.