Contexto
Belo Horizonte tem uma cena cultural intensa e descentralizada: feiras, shows independentes, encontros de bairro e rolês que raramente chegam aos grandes agregadores de eventos. O Mapa dos Rolezinhos nasceu com dois objetivos que se reforçam — resolver um problema real da cidade e servir de laboratório técnico completo, do banco de dados à interface, construído e mantido por uma pessoa.
Problema
A informação sobre esses eventos é efêmera e fragmentada. Ela circula em stories que somem em 24 horas e em grupos fechados, então quem está fora do círculo certo descobre o rolê depois que ele acabou. E falta uma visão espacial: nenhuma dessas fontes responde bem à pergunta “o que está acontecendo perto de mim?”.
Usuário
Dois perfis orientam as decisões de produto. O visitante quer descobrir rolês sem fricção: abrir o mapa, ver o que há por perto e salvar o que interessa — sem criar conta. O curador (papel administrativo) precisa cadastrar, corrigir e remover eventos com rapidez para manter o mapa confiável. Nesta fase, a publicação é centralizada na curadoria de propósito: a confiança no conteúdo importa tanto quanto a interface.
Stack
- JavaScript — SPA sem framework; o domínio (mapa, lista, formulários) não justificava uma camada extra.
- Leaflet + OpenStreetMap — renderização do mapa, marcadores e popups sobre tiles abertos.
- Firebase — Firestore como banco de dados dinâmico e Authentication protegendo o painel administrativo.
- localStorage — favoritos persistidos no próprio navegador, sem backend.
Arquitetura
O frontend é uma SPA estática que conversa diretamente com o Firebase, sem servidor próprio. O Leaflet renderiza o mapa e os marcadores a partir dos eventos lidos do Firestore, então conteúdo novo aparece para o público sem rebuild nem redeploy. A geolocalização do navegador aproxima o mapa da região do usuário — sempre como melhoria opcional, nunca como exigência. O painel administrativo é uma área autenticada da mesma aplicação, executando o CRUD completo sobre a coleção de eventos. Os favoritos vivem apenas no dispositivo.
Funcionalidades
- Mapa interativo com marcadores e detalhes de cada rolê.
- “Perto de mim”: geolocalização via API do navegador para explorar a região atual.
- Favoritos salvos no navegador, disponíveis em visitas futuras sem login.
- Painel administrativo com CRUD completo de eventos (criar, editar, excluir).
- Dados dinâmicos: o mapa reflete o banco em produção sem novo deploy.
Decisões técnicas
- Leaflet/OpenStreetMap em vez de Google Maps. Sem chave de cobrança nem limite de uso enquanto a ideia é validada, e controle total sobre aparência e comportamento. O custo é abrir mão de extras como o Places — que o produto não precisa.
- Firebase em vez de backend próprio. Para um projeto solo, eliminar servidor, ORM e deploy de API encurta o caminho até o produto funcionando. O acoplamento ao fornecedor é um trade-off consciente, aceitável no estágio de validação.
- SPA sem framework. Manipular o DOM diretamente mantém o bundle pequeno e me obrigou a resolver organização de código, estado e renderização sem abstrações prontas — exatamente o tipo de fundamento que os frameworks escondem.
- Favoritos sem conta. Guardar favoritos em localStorage zera a fricção de cadastro e evita armazenar dados pessoais de visitantes. A limitação — favoritos não sincronizam entre dispositivos — é deliberada e está registrada para o futuro.
Segurança
O princípio central: em uma aplicação client-side, a interface não é fronteira de segurança. A configuração do Firebase exposta no bundle não é segredo — o que protege os dados são as regras do Firestore, que tratam toda escrita como operação privilegiada: leitura pública somente do catálogo de eventos, escrita somente para o usuário autenticado da curadoria. O painel fica atrás do Firebase Authentication, e a separação visitante/admin também reduz a superfície de dados: visitante não cria conta, e seus favoritos nunca saem do dispositivo.
Aprendizados
- Segurança em apps serverless é desenho de regras e de modelo de dados — esconder o botão de admin não protege nada.
- Mapa em mobile é um problema próprio: gestos, popups e volume de marcadores pedem decisões de UX e desempenho que o desktop perdoa.
- No Firestore, modelar a partir das consultas (e não do “modelo ideal” relacional) evita migrações dolorosas.
- Publicar cedo, mesmo com curadoria manual, gera um tipo de feedback que nenhum planejamento substitui.
Próximos passos
- Cadastro de eventos pela comunidade, com fila de moderação antes da publicação.
- Filtros por categoria e data diretamente sobre o mapa.
- Evolução para PWA: instalação e leitura offline do que já foi carregado.
- Páginas de evento com link compartilhável, para o rolê circular fora do mapa.