Ir para o conteúdo
← Projetos Projeto Acadêmico

GEA

Sistema de gestão e agendamento de espaços acadêmicos desenvolvido para a FATEC Itu como projeto integrador do curso de ADS. Digitalizou o processo de reserva de salas e laboratórios com frontend React e API REST. Projeto acadêmico desenvolvido em equipe, com liderança do time de frontend.

01

Contexto

A FATEC Itu carecia de um sistema centralizado para agendamento de salas e laboratórios, dependendo de processos manuais propensos a conflitos de horário. O GEA foi desenvolvido como projeto integrador do 4º semestre de ADS, em colaboração com a turma dividida em equipes. Fiquei responsável pela equipe de frontend, liderando cerca de 4 colegas — atribuindo tarefas, facilitando revisões de código e apresentando as entregas de cada sprint para professores e a turma.

02

Papel & Equipe

Papel Líder de Frontend — equipe de ~5 pessoas (incluindo eu)
Duração 2 meses
Equipe Projeto integrador da turma — equipes de frontend e backend separadas
03

Opções consideradas

Sistema monolítico com servidor de templates Rejeitado

Menos complexidade de build, mas dificulta reuso de componentes

SPA React com API REST desacoplada Escolhido

Separação clara de responsabilidades, melhor testabilidade e UX

04

Solução

Arquitetura

SPA React consumindo API REST — frontend e backend completamente desacoplados

Destaques técnicos

  • Autenticação JWT com controle de papéis (admin/professor/aluno)
  • Interface de calendário para visualização e criação de reservas
  • Validação de conflitos de horário no backend

API / Backend: REST

05

Resultados

Métrica Valor
Papéis de usuário 3 — admin, professor, aluno
Autenticação JWT com RBAC — guards no frontend e no backend
Componente de calendário Customizado — sem biblioteca de terceiro
Arquitetura SPA completamente desacoplada de API REST
06

Aprendizados

Liderança de time em ambiente acadêmico

O projeto integrador da FATEC Itu reuniu a turma inteira e a dividiu em equipes de frontend e backend. Assumi a liderança do time de frontend — responsabilidade que incluía distribuir tarefas entre os ~4 colegas do time, garantir integração com a API que o time de backend estava construindo em paralelo, e apresentar o andamento das entregas para os professores orientadores e para a turma a cada etapa.

A gestão do trabalho foi tão desafiadora quanto o técnico: alinhar o ritmo de diferentes pessoas, lidar com entregas atrasadas e manter a interface coerente enquanto componentes eram desenvolvidos em paralelo exigiu comunicação constante e revisões de código frequentes.

O desafio técnico principal

A validação de conflitos de horário ficou no backend — deliberadamente. Mover essa lógica para o cliente pareceria mais rápido, mas criaria inconsistência com múltiplos usuários reservando simultaneamente. A decisão de usar JWT com papéis (admin, professor, aluno) exigiu guards nos dois lados, forçando a equipe a pensar cedo sobre superfície de exposição.

No frontend, construímos um componente de calendário customizado em vez de usar uma biblioteca pronta. Mais trabalho, mas aprendemos os trade-offs de controle versus custo de manutenção na prática — não na teoria.

Os scores de Lighthouse e cobertura de testes serão coletados após o deploy ao vivo (pendente — Fase 7). Qualquer número informado antes disso seria especulação.

Código-fonte ↗