Como o GigTime funciona e como foi feito
Uma vitrine para músicos e para quem contrata música ao vivo: perfis, filtros e conversa direta. Nasceu como projeto acadêmico e foi revisado como peça de portfólio, com foco em arquitetura, segurança, acessibilidade e testes.
Para quem é
Músicos e bandas
- Crie o perfil com gêneros, apresentação, disponibilidade, fotos e um vídeo.
- Encontre bares, casas de shows e eventos em Explorar.
- Use "Contate-me" e combine data, repertório e cachê pelo chat.
Contratantes
- Descreva o seu espaço ou evento e o que procura.
- Filtre músicos por gênero, estado e avaliação.
- Converse com quem combina com o seu palco.
Por que não tem servidor
O GigTime foi feito na disciplina de desenvolvimento web front-end da PUC Minas (2º semestre de 2024), cujo escopo era HTML, CSS e JavaScript. Por isso ele é um site estático: não há back-end, banco de dados nem envio de e-mail. Tudo o que você cadastra fica guardado no seu próprio navegador (Web Storage).
Isso tem consequências que o site assume abertamente:
- Seus dados não saem deste computador e não aparecem em outro navegador.
- Quem usa este mesmo navegador consegue ver os dados guardados nele.
- Não existe recuperação de senha por e-mail. O caminho honesto está em Esqueci minha senha.
A lógica foi separada do armazenamento justamente para que uma API real possa entrar depois sem reescrever as telas (requisito RNF-04).
Arquitetura
Três camadas dentro do navegador, sem build: cada página carrega scripts clássicos na mesma ordem. As regras de negócio ficam em lib/, sem tocar no DOM, e por isso rodam igual no Node para os testes.
Decisões técnicas
- Sem build, scripts clássicos. Cada lib se registra como
window.GigXno navegador e como módulo no Node (padrão UMD). Assim o site abre em qualquer servidor estático e os testes usam o mesmo código. - Armazenamento injetado. As funções recebem o
storagecomo parâmetro; nos testes ele é um objeto em memória, e uma API pode ocupar o mesmo lugar. - Senha com PBKDF2. Sal aleatório de 16 bytes e 600 mil iterações (recomendação OWASP 2023), pela WebCrypto. Hashes antigos (SHA-256 ou texto puro) são trocados no próximo login, sem o usuário perceber.
- Política de segurança de conteúdo. CSP por
<meta>(o GitHub Pages não permite cabeçalhos) sem script nem estilo inline; Bootstrap, fontes e ícones servidos pelo próprio site. - Dados de usuário nunca viram HTML. Entram por
textContentou passam por escape; links de imagem só em https e vídeo só pelo ID do YouTube. - Sessão por aba. Duas abas podem estar logadas com pessoas diferentes (ótimo para testar o chat) e a sessão expira após 2 horas sem uso. Ações sensíveis pedem a senha de novo.
- Acessibilidade. Contraste AA verificado em teste, foco visível, navegação por teclado, erros ligados aos campos e avisos em região
aria-liveno lugar dealert(). - Conteúdo próprio. Personas fictícias e ilustrações geradas por script, sem imagens de terceiros.
Testes
305 testes automatizados com node:test e jsdom cobrem as regras (senha, perfil, filtros, mensagens, sessão, conta) e as páginas de verdade: cada teste carrega o HTML, roda os scripts na ordem e interage como uma pessoa faria. Há também testes de arquitetura: CSP em todas as páginas, contraste AA dos pares de cor, ícones existentes no sprite e estrutura comum das páginas.
Para rodar: npm install e npm test na raiz do projeto.
Teste de carga
Sem servidor, o que se estressa é o navegador: milhares de perfis em Explorar, dezenas de milhares de mensagens no chat e o limite de cerca de 5 MB do localStorage. As medições foram feitas antes e depois das correções; o relatório completo está em docs/carga/ no repositório.
| Cenário | Antes | Depois |
|---|---|---|
| Trocar o filtro com 5 mil perfis em Explorar | 1,2 s | 24 ms |
| Abrir o chat com 25 mil mensagens | 727 ms | 254 ms |
| Enviar uma mensagem com 25 mil gravadas | 511 ms | 43 ms |
| Duas abas enviando 500 mensagens cada | 40% perdidas | nenhuma perdida |
| Lighthouse da Home (desktop): desempenho / acessibilidade | página não pintava | 98 / 100 |
Limitações honestas
- A autenticação é demonstrativa. Sem servidor, quem abre o DevTools consegue gravar outra pessoa na sessão. A senha pedida nas ações sensíveis e o PBKDF2 protegem contra uso casual e contra quem só copia os dados, não contra quem controla o navegador.
- Dados presos a este navegador. Não há sincronização entre dispositivos nem entre navegadores, e limpar os dados do site apaga tudo.
- Espaço limitado. O localStorage guarda cerca de 5 MB: algo como 6 mil perfis ou 30 mil mensagens curtas. Quando enche, o site avisa e oferece restaurar a demonstração.
- Avaliações e selos são fixos. Ainda não existe um fluxo para avaliar depois de um show.
- Imagens por link. Fotos são links https para outros sites; esses sites podem ver o endereço IP de quem abre o perfil.
- Mensagens só com a aba aberta. Não há notificação fora do site; entre abas do mesmo navegador o chat atualiza na hora.
Equipe
Projeto original (2024), curso de Análise e Desenvolvimento de Sistemas da PUC Minas: Carlos Henrique Pereira Silva, Jefferson Luiz Mendonça da Silva, Kauã Eduardo Silva, Lucas Carvalho de Oliveira e William Rocha Leal Viana, com orientação de Humberto Azevedo Nigri do Carmo.
Revisão para portfólio (2026), por Jefferson Luiz Mendonça da Silva: segurança (PBKDF2, CSP, validações), reorganização em camadas, identidade visual, acessibilidade, novas páginas (conta, privacidade, acesso), testes automatizados e teste de carga.