Module 2 · Supabase
Connecting...
Operator:
Total Efforts
shared · all users
Total Outcomes
shared · all users
Conversion Rate
outcomes / efforts
Active Members
contributors
Record Entry
✓ Saved to Supabase
✗ Save failed — check API Inspector
Live Feed
Loading from Supabase...
Total Efforts
Total Outcomes
Conversion
Team Members
Efforts by Type
Loading...
Conversion Rate
outcomes per effort
Activity by Member
Loading...
My Stats
My Efforts
My Outcomes
My Activity Feed
Loading...
What Changed from Module 1
The only code change between Module 1 and Module 2
await window.storage.get('eo_entries')
await fetch(SUPABASE_URL + '/rest/v1/entries?order=datetime.desc', { headers })

await window.storage.set('eo_entries', JSON.stringify(entries))
await fetch(SUPABASE_URL + '/rest/v1/entries', { method: 'POST', headers, body: JSON.stringify(entry) })
The entire UI — forms, dashboard, feed, charts — is identical to Module 1. The only difference is where reads and writes go. That's the lesson: architectural decisions live in the data layer, not the interface.
Live Connection Status
Supabase URLbntomqhidnenhgotkbvn.supabase.co
Auth Keysb_publishable_txc5...52N
Tableentries
ConnectionTesting...
Last Response
Last Latency
Total Records
Architecture Notes · Module 2
✓ What works now (that didn't in Module 1)
· Shared data — every user sees the same entries in real time
· Device independent — log on your laptop, see it on your phone
· Real database — full SQL query capability via PostgREST
· No server to manage — Supabase hosts everything
· Free tier handles thousands of entries easily
✗ New tradeoffs introduced
· API key is visible in browser source — appropriate for internal tools, not public apps
· Data lives in Supabase cloud, not on your machine
· Requires internet — no offline support
· Network latency on every read/write (~100-300ms)