Skip to content
← Projects Academic Project

GEA

Academic space scheduling and management system developed for FATEC Itu as a capstone project for the Systems Analysis and Development program. Digitized the room and lab booking process with a React frontend and REST API. Academic project built in teams; I led the frontend squad of ~4 developers.

01

Context

FATEC Itu lacked a centralized system for scheduling rooms and labs, relying on manual processes prone to scheduling conflicts. GEA was developed as a 4th-semester ADS capstone project, with the class split into frontend and backend teams. I led the frontend team of ~4 peers — assigning tasks, running code reviews, and presenting deliverables at each stage to faculty and the class.

02

Role & Team

Role Frontend Tech Lead — team of ~5 (including me)
Timeline 2 months
Team Class capstone project — separate frontend and backend squads
03

Options considered

Monolithic server-side template system Rejected

Less build complexity, but harder to reuse components

React SPA with decoupled REST API Chosen

Clear separation of concerns, better testability and UX

04

Solution

Architecture

React SPA consuming a REST API — fully decoupled frontend and backend

Technical highlights

  • JWT authentication with role-based access control (admin/professor/student)
  • Calendar interface for viewing and creating bookings
  • Server-side scheduling conflict validation

API / Backend: REST

05

Results

Metric Value
User roles 3 — admin, professor, student
Authentication JWT with RBAC — guards on both frontend and backend
Calendar component Custom-built — no third-party library
Architecture SPA fully decoupled from REST API
06

Learnings

Leading a team in an academic setting

The FATEC Itu capstone brought the whole class together and split it into frontend and backend squads. I took on the frontend lead role — distributing tasks among the ~4 teammates, ensuring integration with the API the backend squad was building in parallel, and presenting progress at each milestone to faculty and the class.

The people-management side was as demanding as the technical work: aligning different paces, handling delayed deliverables, and keeping the interface coherent while components were developed in parallel required constant communication and frequent code reviews.

The main technical challenge

Conflict validation for bookings stayed on the backend — deliberately. Moving that logic to the client would have seemed faster, but it would create inconsistency with multiple users booking simultaneously. Using JWT with roles (admin, professor, student) required guard layers on both sides, forcing the team to think early about attack surface and least-privilege access.

On the frontend, we built a custom calendar component instead of pulling in a third-party library — more work, but we learned the control-versus-maintenance-cost trade-off first-hand rather than in theory.

Lighthouse scores and test coverage will be collected after the live deploy (pending — Phase 7). Any number reported before that would be speculation.

Source code ↗