ResiResi — try the whole thing

ResiResi is a restaurant-reservation platform. Its backend is open — no keys, no roles — on purpose: access control is the gateway's job, not the origin's. It has two tenants, Nino's Pizza and Gino's Pizza, whose software engineers self-serve API keys and manage users & groups from ResiResi's Developers page.

What you'll set up, in plain terms:

• Start ResiResi's local backend on your computer.
• Create an APIblaze proxy from its OpenAPI spec — a checkpoint every request passes through — and tunnel it back to your machine.
• Add logins, API keys, and staff groups to ResiResi's app using APIblaze's ready-made widgets.
• Prove it works: John could open Maria's reservation before — after one rule, he can't (but his own still works, and staff see everything).

Everything runs on your laptop; nothing is deployed anywhere. You'll need Node 20+ and a free APIblaze account (one browser login, for the step that gives your backend a public address).

git clone https://github.com/jayjaychicago/rr
cd rr
./launch.sh

git clone https://github.com/jayjaychicago/rr
cd rr
.\launch.cmd

On Windows, launch.cmd is a plain batch file — no PowerShell execution-policy hassle, and double-clicking it in Explorer works too. Either way your browser opens http://localhost:3333 and the lab takes it from there. Keep the terminal window open; closing it (or Ctrl-C) stops everything cleanly.

Inside the lab, a switch at the top-left decides who runs the commands. Leave it on Web and the lab runs each one for you, streaming the output into the step. Flip it to Terminal and it runs nothing: every step shows its command for you to paste into your own terminal, then you click on — the same walkthrough as a guided doc. Switch whenever you like; it applies from the next command on.

Prefer no browser at all? The same lab runs entirely in your terminal: ./launch_terminal_only.sh (Windows: .\launch_terminal_only.cmd) — same steps, same commands, Enter instead of Run buttons.

• Left — the steps. Each step is a card that explains itself in plain words, shows the exact command it's about to run (copyable), and waits for you to click Run. The output streams right into the card. Nothing runs blind, and nothing runs by itself.
• Middle — ResiResi's Developers page. The page starts with two empty placeholder spots; you watch the API-key and Users & Groups widgets appear in them, live, when the step that adds them runs.
• Right — Nino's Pizza. A real storefront whose every reservation call goes through your proxy. This is where the ending plays out in a real UI, not just in curl output.

Each pane carries an identity strip across the top: who that pane is acting as. The middle pane is always Nino's owner. The storefront pane holds two diners — John and Maria — and clicking one makes you them. There is no sign-in form anywhere in the lab: one click sets the session and reloads the page.

When a step needs you in a pane, a callout pops up over it saying what to click and listing what you should see, so you can check the result rather than guess at it. The header keeps chips with your run's names (proxy resiresi0000, tenant nino0000) so you never lose track of them.

• Set up the API side — start the local backend, log in to APIblaze, create the proxy from the OpenAPI spec, open the tunnel to your machine, and prove a real request round-trips (the exact curl a storefront would send).
• Give ResiResi its Developers page — mint one limited admin key (it stays on the server), make Nino's owner the tenant admin, then start ResiResi's app: the pane opens it already signed in as that owner, and you watch the two widgets replace their placeholders, live and ready to use.
• BEFORE — Nino's storefront comes up on your proxy, and John (a regular diner) opens Maria's reservation. HTTP 200. Not right.
• Fix it in one sentence — put maria in a reservationists group (click it in the widget or let the lab run the commands), then one command turns plain English into enforced authorization:

npx apiblaze rule "Bookings belong to whoever makes them. A reservation may be opened by its owner or by members of the existing group \"reservationists\". The full reservations list is for \"reservationists\" only. Leave every other route open." <your-proxy> --enforce

• AFTER — four calls tell the story: John books a table (201, the proxy records him as the owner) · John opens his own (200) · John tries Maria's (403) · Maria, staff, opens John's (200). Same API key on every call — the person now decides the result.
• And in the UI — the storefront pane parks both diners on the same booking of Maria's, so clicking between John and Maria flips one page between a friendly “this isn't yours to view” and the booking itself. Same URL, same API key; only the person changed. John's own booking still opens, one link away.

• Stop anytime, resume anytime. Ctrl-C, close the laptop, whatever — re-run the launch command and pick Resume: finished steps are skipped, and the tunnel reconnects itself if it dropped.
• A page refresh is safe — the lab replays your whole run back into the browser.
• Names are minted per run (proxy resiresi0000, tenant nino0000), so two people doing the lab never collide — and neither do your own repeat runs.
• Cleanup is automatic — the backend, apps, and tunnel all stop when the lab exits. The proxy stays on your account; delete it anytime with npx apiblaze delete <proxy> --yes.