DEV Community: Achmad Junaedi

Building a High-Speed School Marketplace (Part 2): Multi-Role Security with Supabase RLS

Achmad Junaedi — Mon, 05 Oct 2026 05:05:01 +0000

This is Part 2 of our technical series on building a high-speed, lightweight school marketplace. In Part 1: Why We Ditched Frameworks for Vanilla JS & PWA (https://dev.to/juna_go15/building-a-high-speed-school-marketplace-why-we-ditched-frameworks-for-vanilla-js-pwa-27dl), we discussed how we optimized the frontend for budget mobile devices. Today, we look at the backend architecture.

When planning the architecture for Aksara-Mart—our digital marketplace for vocational school canteens and cooperatives—we faced a fundamental infrastructure question:

Do we really need to build, maintain, and scale a traditional custom backend server (like Node.js/Express, Python, or Go) just to shuttle data between the browser and the database?
For a school environment, maintaining a traditional backend comes with real trade-offs:

Infrastructure & Hosting Overhead: A dedicated server needs 24/7 uptime monitoring, memory management, and scaling configuration for peak recess traffic.

Maintenance Burden: API routes, middleware controllers, and ORM abstractions require continuous patching and maintenance.

Unnecessary Latency: Every simple query (browsing the lunch menu, checking an order status) has to make an extra hop through an intermediate API server layer. We wanted an architecture that could minimize backend server workload while keeping running costs close to zero. That led us to Supabase. By allowing our frontend JavaScript to communicate directly with PostgreSQL via auto-generated APIs and WebSockets, we could offload the bulk of routine read queries directly to the client. However, letting client-side JavaScript query a database directly sounds like a security nightmare—unless you have a bulletproof authorization layer built into the database itself. That is where PostgreSQL Row Level Security (RLS) becomes the cornerstone of the entire system.

The Architecture: Direct Client Queries Without the Middleman In a traditional web application, every user request passes through three layers:

[ Browser (Client) ] ──▶ [ Custom API Server (Express/Node) ] ──▶ [ Database ]

The API server spends most of its CPU cycles doing mundane tasks: authenticating tokens, verifying if a user is allowed to read a row, running the query, and formatting JSON.
With Supabase and PostgreSQL RLS, we simplified the architecture into a direct, high-performance two-tier model:

[ Browser (Vanilla JS Client) ] ──────────────▶ [ Supabase PostgreSQL + RLS ]
• Direct catalog SELECT                         - Kernel-level row authorization
• Direct order history lookup                   - Instant query evaluation (< 3ms)
• Real-time WebSocket subscriptions             - Atomic RPC stored procedures

The Advantages:
• Zero Backend Server Maintenance: No intermediate server processes to crash, restart, or run out of memory during a rush.
• Minimal Compute Overhead: PostgreSQL handles filtering and JSON serialization natively in C, which is vastly faster than parsing objects in Node.js.
• Direct Client Queries: Frontend JavaScript can fetch exactly the columns it needs, when it needs them, directly from the client.

The Core Problem: Securing Direct Database Access If frontend JavaScript talks directly to the database using a public API key, what prevents a student from querying other users' private orders or inspecting canteen cost margins? This is where Row Level Security (RLS) comes in. Instead of writing authorization logic in backend middleware (if (req.user.id !== order.user_id) return res.status(403)), the authorization rules are compiled directly into PostgreSQL table definitions. • Without RLS: A client query supabase.from('orders').select('*') returns every order in the database. • With RLS: PostgreSQL automatically injects an internal filter into the query plan:

-- Automatically enforced by PostgreSQL on every query
WHERE email_customers = auth.jwt() ->> 'email'

Even if a user inspects the network tab and writes a custom script asking for all records, the database engine guarantees they only receive the rows they are explicitly permitted to see.

Managing Roles Across the School Ecosystem A school marketplace serves several distinct groups with different permissions: | Role | Access Scope | How Queries Are Handled | | :--- | :--- | :--- | | siswa (Students) | Browse active products, view own order history. | Direct client SELECT constrained by RLS. | | guru (Teachers) | Same as students, with priority fulfillment flags. | Direct client SELECT constrained by RLS. | | kasir (Cashiers) | View all active incoming orders, print receipts. | Direct client SELECT with staff privileges; no direct price/stock editing. | | manajer (Managers) | Manage catalog items, update stock, view revenue. | Full CRUD permissions on product tables via RLS. | | admin (System Admins) | System-wide configuration and role management. | Full administrative access. | The admin_role Table To keep role checks clean and reliable, we maintain a dedicated role table in PostgreSQL:

CREATE TABLE public.admin_role (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT UNIQUE NOT NULL,
role TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'active'
);
ALTER TABLE public.admin_role ENABLE ROW LEVEL SECURITY;

Practical Gotchas We Addressed:

Case-Insensitive Emails: Mobile keyboards often capitalize the first letter of an email (User@school.edu). Always use lower(trim(email)) in policies to prevent login lockouts.
Dual-Spelling Tolerance: In bilingual environments, staff may enter roles in English or Indonesian (manager vs manajer, cashier vs kasir). We check role aliases with IN ('manager', 'manajer', 'cashier', 'kasir') so minor spelling differences don't break authentication.
The Separation of Concerns: Direct Reads vs Server-Side Writes
Allowing frontend JavaScript to query the database directly works brilliantly for reads, but transactional writes require a different boundary.
A. Direct Client Reads (Safe via RLS)
Frontend JavaScript directly reads from the database for:
• The product catalog:

// Direct client query in skripmart.js
const { data: products } = await supabase
.from('product_list')
.select('id, name, price, stock, image_url')
.eq('status', 'active');

RLS ensures that wholesale costs (modal_price) and archived items are filtered out before data leaves PostgreSQL.
• Order tracking:

// Customers only receive their own orders
const { data: myOrders } = await supabase
.from('orders')
.select('*')
.order('created_at', { ascending: false });

B. Controlled Server-Side Writes (Via Database RPC)
While reading data directly from JavaScript is safe, creating orders and modifying stock should never happen via direct client INSERT or UPDATE:

// ❌ ANTI-PATTERN: Never allow direct client inserts for financial transactions
await supabase.from('orders').insert({
total_price: clientCalculatedTotal, // Client could tamper with this value!
items: cartItems
});

If we allowed direct client inserts on the orders table, a user could theoretically alter prices or bypass stock limits.
Instead, we follow a simple architectural rule:

Frontend JavaScript reads data directly using RLS.
Frontend JavaScript writes transactions via PostgreSQL Stored Procedures (RPC).
When a student checks out, the client invokes an RPC procedure (v2_create_order):

// ✅ SECURE: Transaction logic runs atomically inside PostgreSQL
const { data, error } = await supabase.rpc('v2_create_order', {
p_customer_name: userProfile.name,
p_delivery_type: deliveryOption,
p_items: cartPayload
});

Inside this procedure, the database recalculates prices from the official catalog, checks remaining stock, decrements inventory, and creates the order records in a single atomic transaction.

What We Gained from This Architecture By offloading query processing directly to the client and database engine:
Zero Backend Maintenance: We do not maintain or pay for a custom Node.js/Express server layer.
Sub-3ms Authorization Overhead: RLS policy checks happen natively within PostgreSQL's query optimizer with virtually no latency penalty.
High Reliability During Traffic Spikes: When hundreds of students browse the menu simultaneously during recess, Supabase and Cloudflare serve the requests directly without choking an intermediate web server.
Complete Data Privacy: Every customer and staff member only receives data that belongs to their assigned role.

What's Next in Part 3?
With direct reads secured by RLS and client-side queries running smoothly, we still had to solve one critical concurrency problem:
During the 15-minute school break, dozens of students click "Checkout" at the exact same millisecond for the last few items in the canteen.
How do we prevent race conditions and overselling without a heavy application server?
In Part 3: Atomic Checkouts & Zero Overselling with PostgreSQL RPC, we will break down how we implemented pessimistic row locking (FOR UPDATE) inside PostgreSQL to handle high-concurrency checkout spikes in under 42 milliseconds!

Ditched React for our school marketplace app 👇 Bundle: <50KB. Load time on a $80 Android: 320ms. Story + architecture breakdown here #DEVCommunity #webdev

Achmad Junaedi — Wed, 09 Sep 2026 08:44:07 +0000

Achmad Junaedi

Sep 9

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

#javascript #pwa #webdev #programming

4 min read

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

Achmad Junaedi — Wed, 09 Sep 2026 08:08:41 +0000

This is Part 1 of a 4-part series on building a high-speed, race-condition-proof digital marketplace for schools using Vanilla JS, Supabase RLS, PostgreSQL RPC, and Cloudflare Workers.

In the modern web ecosystem, starting any web project without reaching for React, Next.js, or Vue has almost become taboo.

Yet, when our team at Setvy sat down to architect Aksara-Mart—a digital marketplace serving thousands of students and teachers across our vocational high school—we made an intentional, contrarian decision:

We threw out the frontend frameworks and built the entire client in pure Vanilla JavaScript, modern CSS, and PWA standards.

Why? Because when your user base consists of students using second-hand, $80 Android phones running on limited prepaid mobile data, developer convenience cannot come at the expense of end-user performance.

Here is what we learned, why it paid off, and how you can implement a high-speed Vanilla JS architecture.

1. The Reality of School Hardware

Before writing a single line of code, we profiled our target environment:

Hardware Constraints: 65% of students carry entry-level devices with 2GB to 3GB of RAM, powered by aging Quad-core MediaTek or Snapdragon 400-series processors.
Prepaid Data, Not Wi-Fi: Most students don't rely on school Wi-Fi at all—they browse on their own prepaid mobile data plans (kuota). Every megabyte is paid out of their pocket money, so a heavy page literally costs them. On top of that, when hundreds of phones hit the same nearby cell tower during recess—from inside concrete classroom buildings—effective speeds often drop to 2G/3G levels.
The Recess Rush: Students have a very brief window between bells to browse the canteen menu, order food, and pick it up. A 4-second loading screen means they don't eat.

The Modern Framework Tax on Budget Devices

A barebones Next.js or React e-commerce template typically ships:

250 KB – 500 KB of minified JavaScript.
JavaScript Parsing & Compilation Time: On an iPhone 16 or M3 MacBook, parsing 300KB of JS takes 15 milliseconds. On a budget Android phone, it takes 1,200 to 2,500 milliseconds.
Hydration Lag (Total Blocking Time): The page looks loaded, but clicking the "Add to Cart" button does nothing because the JavaScript thread is frozen during hydration.

On high-end dev laptops, this latency is invisible. On budget devices, it ruins the experience.

2. The Architecture: Under 50 KB, 60 FPS

By returning to web fundamentals, we achieved:

Total Initial JS + CSS Payload: < 48 KB (gzipped).
First Contentful Paint (FCP): ~320 ms on low-end 4G.
Time to Interactive (TTI): Instantaneous.

Here is how our client structure looks:

aksaramart/
├── public/
│   ├── index.html       # Semantic HTML5 shell & modal templates
│   ├── skripmart.js     # Modular Vanilla JS logic (~35 KB)
│   ├── stylemart.css    # Clean, framework-free CSS with CSS Variables
│   ├── sw.js            # PWA Service Worker for caching & offline resilience
│   └── manifest.json    # Progressive Web App configuration

3. Clean Patterns for Vanilla JS State & DOM

Building with Vanilla JS doesn't mean writing chaotic spaghetti code. We used modern ES6+ patterns, event delegation, and atomic state rendering.

Pattern A: Modular State Store

// A lightweight, reactive-free state store
const appState = {
    cart: JSON.parse(localStorage.getItem('aksara_cart') || '[]'),
    products: [],
    currentUser: null,
    activeCategory: 'all'
};

function saveCart() {
    localStorage.setItem('aksara_cart', JSON.stringify(appState.cart));
    renderCartBadge();
}

function addToCart(productId) {
    const product = appState.products.find(p => p.id === productId);
    if (!product || product.stock <= 0) return;

    const existing = appState.cart.find(item => item.id === productId);
    if (existing) {
        if (existing.qty < product.stock) existing.qty++;
    } else {
        appState.cart.push({ id: product.id, name: product.name, price: product.price, qty: 1 });
    }
    saveCart();
    renderCartUI();
}

Pattern B: High-Performance Event Delegation

Instead of attaching individual click listeners to hundreds of catalog items, we attached a single listener to the container:

document.getElementById('catalogGrid').addEventListener('click', (e) => {
    const btn = e.target.closest('[data-action="add-to-cart"]');
    if (!btn) return;

    const productId = btn.dataset.productId;
    addToCart(productId);

    // Smooth micro-animation without any animation library
    btn.classList.add('scale-bounce');
    setTimeout(() => btn.classList.remove('scale-bounce'), 250);
});

4. Making It a True App: Progressive Web App (PWA)

Most students won't go to Google Play or the App Store to install a canteen app. But with PWA standards, they can install it directly from the browser in 1 tap.

Step 1: Web App Manifest (`manifest.json`)

{
  "name": "Aksara Mart - Kantin & Koperasi Sekolah",
  "short_name": "AksaraMart",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#10b981",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

Step 2: Custom "Install App" Topbar Trigger

Browsers often show a subtle or clunky native install banner. We intercepted the beforeinstallprompt event to give students an explicit, high-visibility install button in the top navigation:

let deferredPrompt;
const installBtn = document.getElementById('installAppBtn');

window.addEventListener('beforeinstallprompt', (e) => {
    // Prevent default mini-infobar
    e.preventDefault();
    deferredPrompt = e;
    // Show our custom branded install button
    if (installBtn) installBtn.style.display = 'inline-flex';
});

installBtn?.addEventListener('click', async () => {
    if (!deferredPrompt) return;
    deferredPrompt.prompt();
    const { outcome } = await deferredPrompt.userChoice;
    console.log(`User install outcome: ${outcome}`);
    deferredPrompt = null;
    installBtn.style.display = 'none';
});

Step 3: Cache-First Service Worker (`sw.js`)

To guarantee instant loading even when the cellular signal drops (or a student's data quota runs out mid-week), our Service Worker caches core static shell assets—so repeat visits cost almost zero data:

const CACHE_NAME = 'aksaramart-v1.4';
const STATIC_ASSETS = [
    '/',
    '/index.html',
    '/skripmart.js',
    '/stylemart.css',
    '/manifest.json',
    '/icons/icon-192.png'
];

self.addEventListener('install', (e) => {
    e.waitUntil(
        caches.open(CACHE_NAME).then(cache => cache.addAll(STATIC_ASSETS))
    );
    self.skipWaiting();
});

self.addEventListener('fetch', (e) => {
    // Only cache static GET requests, let API requests go to network
    if (e.request.url.includes('/rest/v1/') || e.request.url.includes('/rpc/')) {
        return;
    }
    e.respondWith(
        caches.match(e.request).then(cached => cached || fetch(e.request))
    );
});

5. The Performance Verdict

Here is the Lighthouse audit comparison run on an emulated Moto G4 with a throttled 3G network:

Metric	Typical Next.js / React E-Commerce	Aksara-Mart (Vanilla JS + PWA)
Performance Score	62 / 100	99 / 100
First Contentful Paint (FCP)	2.9 s	0.34 s
Total Blocking Time (TBT)	840 ms	0 ms
Speed Index	3.4 s	0.6 s
Total Transfer Size	380 KB	46 KB

6. Conclusion

Ditching frameworks for Vanilla JS proved to be a resounding success for our students and teachers. The app launches immediately, remains completely immune to hydration freezes, and preserves scarce phone battery and memory.

However, a fast frontend is completely meaningless if the underlying database is vulnerable. How do we secure transaction data from curious IT vocational students who open Inspect Element / DevTools to try altering menu prices from $1.50 to $0.01?

In the next article, we'll dive deep into our Zero-Trust database security architecture using Supabase Row Level Security (RLS) and multi-role governance.

I Stopped Using Gemini 3.1 Pro for Agentic Coding — Why I Moved to Gemini 3.7 Flash High Mode

Achmad Junaedi — Tue, 01 Sep 2026 11:32:50 +0000

I landed my first Point of Sale (POS) SaaS client project and built it inside Google Antigravity, trusting Gemini 3.1 Pro for all agentic coding. Bad move. Midway through, severe bugs hit—fixing sales inputs completely broke my dashboard analytics.

Frustrated, I switched to the GPT stack (Codex, GPT-5.5, GPT-5.6 Sol). But that brought a new headache: token quotas drained in minutes and API bills went through the roof.

The breakthrough? Community stats on Agent Arena showed Flash models beating 3.1 Pro in agentic tasks. Desperate, I tested Gemini 3.6 Flash and it was surprisingly solid.

1. The Beginning: Falling for 3.1 Pro Hype
When Google dropped Gemini 3.1 Pro in February 2026, tech Twitter hyped its ARC-AGI-2 benchmark scores as the ultimate problem solver.
Early on, 3.1 Pro handled high-level whiteboard concepts fine:
• System Architecture: Mapping schemas and ERDs.
• Business Logic: Outlining business logic flows.
• Edge Cases: Spotting potential edge cases.

2. Client Pressure & Regression Hell
I secured a major deal with a client who paid 50% upfront. Expectations were high, and that's where things went downhill.
A retail POS requires tight database relations: transactions, inventory sync, multi-outlet stock, and live dashboard revenue summaries. When I instructed Gemini 3.1 Pro in Antigravity to build the sales input module:

Fatal Regressions: The sales input worked, but the dashboard suddenly went crazy. The model rewrote existing SQL aggregation queries without respecting cross-module dependencies.
Lost Query Logic: It repeatedly forgot critical database filter conditions (like tenant IDs or soft-delete flags), causing messy data anomalies.
Deadline Panic: The client wanted deliverables per contract, and I was sweating because the code kept breaking.

3. Fleeing to GPT & The Token Trap
Panicking about deadlines, I switched to the OpenAI ecosystem:
• Codex / GPT-5.5 (Medium): Daily coding assistant.
• GPT-5.5 (High Reasoning): Complex SQL logic.
• GPT-5.6 Sol: Heavy artillery for deep debugging.
While reasoning was solid, a new problem popped up: tokens burned out insanely fast.

Running heavy models like GPT-5.6 Sol and 5.5 High across autonomous agentic loops burned quotas in no time. I needed a workhorse that didn't drain my wallet.

4. Community Outrage: It Wasn't Just Me
My frustration wasn't unique. On the Google AI Developers Forum , a thread titled "Unacceptable Antigravity Quotas for Gemini 3.1 Pro – Workflow Completely Blocked!" had racked up roughly 60 upvotes and 19 replies within days.

One developer, Hauke_Walden, summed up the core complaint: "...it is totally unacceptable that the quota usage is so intransparent, and even worse, the totally random 'refresh' policy... It's like a car that sometimes works, sometimes it doesn't. That's ok for a hobbyist and his vintage car, but not for a cab driver."

Another, madnz-08, described a specific bug: "Yesterday my quota dropped from 60% to 0% without any prompt, and the worst part was seeing the reset time set to 50+ hours."

A third, MrTos, put it bluntly: "It is unacceptable to be stuck at 10 prompts on Gemini 3.1."

The pattern in the thread was consistent: vanishing quotas, lockout timers reported as high as 133–167 hours, and reports of paying developers getting locked out mid-project.

5. The Pivot: Testing Gemini 3.6 Flash
Hunting for a leaner alternative, I saw rankings on Agent Arena praising Flash models for agentic tool use.
Curious, I tested Gemini 3.6 Flash in Antigravity:
• Blazing Speed: Instant feedback loops without lag.
• Quota Sanity: No panic about hitting rate limits mid-session.
• Sane Diffs: It stayed in its lane without aggressively trashing outside files.
It proved lightweight models were getting unwarranted hate.

6. August: Brother's WhatsApp Tip & The Jump to 3.7 Flash
In August, my younger brother sent me a WhatsApp message: "Bro, Google just dropped Gemini 3.7 Flash."
As reported by VentureBeat, Google built 3.7 Flash specifically for coding and agentic loops, with a 50% introductory discount ($0.75 / 1M input, $3.75 / 1M output).
Having seen good results with 3.6 Flash, I wanted to see if Google really pulled off deep reasoning on a Flash model without killing speed.

7. The Proof: Gemini 3.7 Flash (High Mode) in Antigravity
I opened Antigravity, picked Gemini 3.7 Flash, and enabled Thinking Mode: High. The leap in quality was immediate:

Blazing Fast & Token-Efficient Inference stayed snappy even with extended thinking on. In fast agent loops, code fixes felt instant without distracting pauses, while token burn remained low.
Complex Database Queries Handled Smoothly Any fear that Flash would choke on multi-table queries disappeared. It surgically edited the sales module without touching outside files, kept dashboard queries in sync, and maintained schema rules without destructive side effects.
Cleaner Code & Only Minor Tweaks There were a few minor formatting adjustments, but the code structure was clean. Those small tweaks took one quick prompt to fix—not fatal structural bugs. I delivered the client project right on time.

Conclusion
This client project taught me a valuable lesson: in daily agentic coding, diff discipline, fast inference, and token efficiency matter way more than benchmark scores on paper.
From Agent Arena tests with 3.6 Flash to the leap in Gemini 3.7 Flash, it proved Flash models with thinking mode aren't just "cheap alternatives"—they are solid workhorses that handle heavy code cleanly and safely.
If you're building a SaaS and stuck between regression bugs or sky-high token bills, give Gemini 3.7 Flash a run in Google Antigravity.

Written by Achmad Junaedi — Founder of setvy.id & Vocational Educator at SMKN 10 Surabaya, Indonesia.

DEV Community: Achmad Junaedi

Building a High-Speed School Marketplace (Part 2): Multi-Role Security with Supabase RLS

Ditched React for our school marketplace app 👇 Bundle: <50KB. Load time on a $80 Android: 320ms. Story + architecture breakdown here #DEVCommunity #webdev

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

1. The Reality of School Hardware

The Modern Framework Tax on Budget Devices

2. The Architecture: Under 50 KB, 60 FPS

3. Clean Patterns for Vanilla JS State & DOM

Pattern A: Modular State Store

Pattern B: High-Performance Event Delegation

4. Making It a True App: Progressive Web App (PWA)

Step 1: Web App Manifest (manifest.json)

Step 2: Custom "Install App" Topbar Trigger

Step 3: Cache-First Service Worker (sw.js)

5. The Performance Verdict

6. Conclusion

I Stopped Using Gemini 3.1 Pro for Agentic Coding — Why I Moved to Gemini 3.7 Flash High Mode

Step 1: Web App Manifest (`manifest.json`)

Step 3: Cache-First Service Worker (`sw.js`)