Loading...
Zashio
An AI-powered campus placement and recruitment platform. Students apply to jobs, recruiters manage pipelines, and admins oversee the full hiring workflow — all behind role-based access control.
Core Engineering Achievement
Built multi-role authentication with JWT and Supabase Row-Level Security, separating Student, Recruiter, and Admin data at the database layer.
System Interface & Feature Tour
home-town-hub-pi.vercel.app
Recruiter View
Click for Fullscreen
Production Stats
0
User Roles (RBAC)0+
API Route Groups0+
Git Commits0
Core DB EntitiesJWT + Supabase Auth
Auth
PostgreSQL (Relational)
Database
Row-Level Security
Access Control
The Challenge
Campus placement offices manage hundreds of student applications manually — spreadsheets, email threads, and no unified tracking system. Students have no visibility into their application status and recruiters have no structured way to compare candidates.
Project Goals
- Build separate, purpose-built interfaces for Students, Recruiters, and Admins without exposing each other's data.
- Enforce access control at both the API and database layer — not just in the UI.
- Give recruiters a simple workflow to post jobs, review applicants, and update statuses.
Technology Stack
frontend
backend
database
infrastructure
tooling
System Architecture
Client Layer
Vite + React with TypeScript. Protected routes using React Router v6. Each role gets its own route tree. Tailwind CSS for layout.
Application Layer
Node.js + Express REST API. Middleware validates JWT on every protected endpoint and extracts the role from the token payload before processing.
Data Layer
PostgreSQL on Supabase. Four core tables: users, companies, jobs, applications. Supabase RLS policies ensure database-level isolation per user.
Performance & Security Architecture
⚡ Performance & Scalability
Vite's code splitting keeps the initial bundle lean. Each role's dashboard is a separate route chunk, so a student's session never loads recruiter-specific code.
🔒 Security & Access Control
Passwords hashed with bcrypt. JWT contains role and userId — verified server-side on every request. Supabase RLS adds a second enforcement layer at the database.
Engineering Decisions & Trade-offs
PostgreSQL over MongoDB
Reasoning
The data has clear relationships: a job belongs to a company, an application links a student to a job. Relational constraints prevent orphaned records and make queries straightforward with JOINs.
Trade-off
Requires migration management and a fixed schema, which slows down early iteration compared to a document store.
Supabase RLS over API-level filtering
Reasoning
If authorization logic lives only in the API layer, a bug could expose another recruiter's applicants. RLS enforces it at the database — even a direct DB connection respects the policy.
Trade-off
RLS policies can be difficult to debug and require learning Supabase's policy syntax carefully.
Key Results & Production Impact
- Working platform with three fully separated role experiences and complete job-application workflow.
- Zero cross-role data leakage — verified by logging in as different users and inspecting API responses.
- Clean schema design that could be extended with more entities (interviews, feedback) without restructuring.
Engineering Takeaways & Lessons Learned
Authorization belongs at the data layer, not just the UI. Building RLS early meant I never had to audit the API for data leaks — the database simply refused unauthorized queries.