How I Built Maniesta Campus: A Campus Management System with React and Node.js

Usman Murtaza — Thu, 24 Sep 2026 11:50:51 +0000

Educational institutions run on paperwork and spreadsheets. Student records live in one file, attendance in another, grades somewhere else, and schedules — usually — in someone's head.

I kept hearing the same complaint from small colleges and coaching centers: "We need something simple that just works." So I built Maniesta Campus — a role-based campus management system with separate dashboards for admins, faculty, and students.

🔗 Live Demo: maniestacampus.netlify.app

This post walks through how I designed the system, the technical decisions I made, and the parts that were harder than expected.

The Problem

Before writing a single line of code, I mapped out what an actual campus needs:

Admins need to manage students, faculty, courses, and enrollments from one place
Faculty need to mark attendance, upload grades, and view their class rosters
Students need to see their schedule, grades, and enrolled courses without asking anyone

The core challenge was role-based access — one login system that serves three completely different user journeys. A student should never see admin controls, and a faculty member shouldn't be able to edit another faculty member's course.

Traditional CRUD apps don't handle this well. You end up with if (user.role === 'admin') scattered everywhere. I wanted something cleaner.

Tech Stack Decisions

Here's what I picked and why:

React — the UI needed to render completely different dashboards based on role. Component composition made this natural.
Node.js + Express — a straightforward REST API that I could iterate on quickly. No need for anything heavier.
MongoDB — campus data is hierarchical and evolves fast. Student records have different fields than faculty records, and course structures change per institution. Flexible schemas saved me from constant migrations.
JWT — stateless authentication means the API doesn't need session storage. Scales horizontally, and the frontend can hold the token with the user's role embedded in it.
Tailwind CSS — for fast UI iteration. When you're building three dashboards, you don't want to write custom CSS for every component.

Architecture Overview


┌──────────────────┐
│   React Client   │
│  (3 dashboards)  │
└────────┬─────────┘
│  HTTP + JWT
▼
┌──────────────────┐
│  Express API     │
│  - Auth routes   │
│  - RBAC middleware│
│  - Resource routes│
└────────┬─────────┘
│
▼
┌──────────────────┐
│    MongoDB       │
│  users, courses, │
│  grades, etc.    │
└──────────────────┘

Every request flows through an authentication middleware first, then a role-check middleware, then the actual route handler. Nothing reaches the database without passing the role gate.

The Core: Role-Based Access Control

The RBAC system is where most of the design effort went. Here's the middleware that powers it:

// middleware/auth.js
const jwt = require('jsonwebtoken');

// Verify the JWT and attach the user to the request
const authenticate = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) {
    return res.status(401).json({ error: 'No token provided' });
  }
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded; // { id, role }
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
};

// Only allow specific roles to proceed
const requireRole = (...roles) => (req, res, next) => {
  if (!roles.includes(req.user.role)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  next();
};

module.exports = { authenticate, requireRole };

Now any route can declare its own access rules cleanly:

// routes/courses.js
const { authenticate, requireRole } = require('../middleware/auth');

// Anyone logged in can view courses
router.get('/courses', authenticate, listCourses);

// Only admins can create courses
router.post('/courses', 
  authenticate, 
  requireRole('admin'), 
  createCourse
);

// Faculty can update grades for their own courses
router.patch('/courses/:id/grades',
  authenticate,
  requireRole('faculty'),
  updateGrades
);

This pattern scales. If I ever add a "teaching assistant" role, I just pass it into requireRole — no other code changes.

Frontend: One App, Three Dashboards

On the frontend, I used a simple pattern — the auth context holds the user, and the dashboard component switches on the role:

const Dashboard = () => {
  const { user } = useAuth();

  switch (user.role) {
    case 'admin':
      return <AdminDashboard />;
    case 'faculty':
      return <FacultyDashboard />;
    case 'student':
      return <StudentDashboard />;
    default:
      return <Navigate to="/login" />;
  }
};

Each dashboard imports its own set of components. The shared pieces — navbar, notifications, profile, logout — live outside and are reused across all three.

A protected route wrapper handles the auth check on the way in:

const ProtectedRoute = ({ allowedRoles, children }) => {
  const { user } = useAuth();
  if (!user) return <Navigate to="/login" />;
  if (allowedRoles && !allowedRoles.includes(user.role)) {
    return <Navigate to="/unauthorized" />;
  }
  return children;
};

With this in place, adding a new admin-only page is a single line:

<ProtectedRoute allowedRoles={['admin']}>
  <ManageFaculty />
</ProtectedRoute>

Challenges I Didn't Expect

Schema design for multiple user types.
At first I considered separate collections for students, faculty, and admins. That meant three login flows and three auth systems. Then I realized a single users collection with a role field plus role-specific optional fields is much simpler. When a student is also a teaching assistant, I just update the role — no data duplication.
Keeping the JWT payload small.
I only embed { id, role } in the token. Everything else — name, email, permissions — is fetched on demand. Bigger tokens are slower to verify, and they become stale as soon as a user updates their profile.
Grade calculation edge cases.
What counts as an "A"? Every institution has its own grading scale. I ended up making the scale configurable per institution and storing it in the database, so the grading logic stays data-driven rather than hardcoded.

What I Learned

· Design RBAC before writing features. Retrofitting access control into an existing app is brutal. Getting it right upfront made everything else easier.
· Keep JWTs thin. Only store what the token actually needs to prove identity. Fetch the rest.
· Data-driven grading beats code-driven grading. When in doubt, make it configurable.
· Component composition in React scales beautifully for dashboards. Three completely different UIs coexisting in one app turned out to be much cleaner than I expected.

Try It Out

· 🔗 Live Demo: maniestacampus.netlify.app
· 💻 Source Code: github.com/usmannmurtazaa/maniesta-campus-os

You can log in as different roles to see how the dashboards change. The RBAC behaviour is the most interesting part to explore.

What's Next

A few features I'm planning:

· Real-time notifications with Socket.io for grade updates and enrollment changes
· An analytics dashboard for admins (enrollment trends, popular courses)
· A mobile app built with React Native that shares the same API
· Bulk import from Excel so institutions can migrate their existing records

About the Author

I'm Usman Murtaza, a Full Stack Developer based in Karachi, Pakistan. I build modern web applications with React, Node.js, and MongoDB, and I'm the creator of the Maniesta ecosystem — a collection of web products and utilities.

Maniesta Campus is one of those products. Others include Maniesta Resume AI, Maniesta Suite, and the Maniesta brand platform itself.

· 🌐 Portfolio: usmanmurtaza.netlify.app
· 💻 GitHub: github.com/Usmannmurtazaa
· 💼 LinkedIn: linkedin.com/in/Usmannmurtazaa
· 🐦 Twitter/X: @usman_murtazaa

If you found this useful, follow me here on Dev.to — I write about full-stack development, React patterns, and building products from scratch.

Built by Usman Murtaza - see more projects at usmanmurtaza.netlify.app

DEV Community: Usman Murtaza

How I Built Maniesta Campus: A Campus Management System with React and Node.js

The Problem

Tech Stack Decisions

Architecture Overview

The Core: Role-Based Access Control