Client work / collaborative full-stack

SPECTRA CBT Platform

An event-duration computer-based testing platform built with Next.js and Supabase.

Period
Mar - Apr 2026
Role
Collaborative full-stack developer
Delivery
Event-duration deployment

Overview

Context before technology.

My scope covered Supabase integration, Server Actions, SSR/CSR decisions, data state, timeout and participant-ban logic, plus deployment configuration.

Application boundaries

Browser state, server actions, managed data services.

  1. Browser

    Participant and admin UI

    Client Components, React Context, localStorage, browser auth lookup, and ban-event subscription.

  2. Next.js

    App Router runtime

    Middleware, Server Components, Server Actions, data access, and cookie-aware SSR client.

  3. Supabase

    Managed boundary

    Auth, Postgres, selected server-only privileged operations, and Realtime publication.

Source-backed architecture. Browser interaction invokes Server Actions; no first-party API-route layer was inspected. Vercel deployment is user-confirmed.

Service-role operations stay in selected server actions, never browser code. Event-duration implementation is not presented as security-hardened production software.

  1. 01

    Admin monitoring snapshot

    Admin page loads current participant status through server-rendered query.

  2. 02

    Ban action

    Admin Server Action inserts participant identifier into ban table.

  3. 03

    Realtime publication

    Supabase publishes matching insert event to connected clients.

  4. 04

    Participant browser

    Subscription matches current participant identifier and reads persisted local answers.

  5. 05

    Submission attempt

    Browser invokes normal submission Server Action after clearing local state.

  6. 06

    Score and persist

    Server authenticates, scores, inserts submission, and removes active assignment.

Participant-ban flow. Connected Supabase revision includes the ban table in Realtime publication; admin monitoring itself remains snapshot-based.

Realtime notification triggers browser-side submission attempt, not guaranteed forced submission. Connected browser, active subscription, and successful Server Action remain required.

  1. Timer

    Browser reaches end time

    Browser-side countdown trigger

  2. Ban

    Realtime ban notification

    Delivery-dependent browser trigger

  3. Answers

    Read persisted answers

    Participant localStorage state

  4. Score

    Server Action scoring

    MCQ +1/-1/0; essay keyword threshold +2/-1/0

  5. Result

    Weighted submission

    60% MCQ plus 40% essay; insert then assignment cleanup

Timeout and ban triggers converge on one submission path. Answer keys remain server-side when questions are delivered to participant browser.

Timer is browser-driven. Submission reads localStorage rather than live React Context, and insert plus assignment cleanup are not transactional.

Collaboration boundary

This was collaborative delivery. My work focused on logic-heavy application behavior and deployment setup; a teammate handled design and layout-heavy work.

The project supports participant and administrative workflows for an event-duration testing context.

Application decisions

The implementation combines Server Components with Client Components, middleware, and Server Actions rather than a separate first-party API route layer. Supabase provides Auth, Postgres, and a browser Realtime subscription for participant-ban inserts; selected privileged operations stay server-side.

Owned logic includes participant-oriented data state, answer persistence, question delivery without answer keys, countdown submission, scoring, and participant-ban flow. Realtime delivery notifies connected participant browsers, which then attempt normal submission.

Evidence boundary

Connected event-deployed Supabase revision confirms the application schema, scoring functions, and ban-table Realtime publication. It also has material authorization boundaries, including public application tables without RLS, so this event-duration system is not presented as security-hardened production software.

Admin monitoring is snapshot-based, ban and timeout actions depend on browser participation, and no usage, uptime, scale, or independently verified delivery outcome is claimed.

Working set

Technology serves the system.

  • Next.js
  • TypeScript
  • Supabase
  • React
  • Vercel