Nu! Carnaval 2026

Contexto

O Carnaval de rua de Belo Horizonte leva multidões para os bairros — e leva junto a rede celular ao limite. Este é um projeto independente, sem afiliação ou endosso de marcas, criado como companheiro do folião para a edição 2026. Tecnicamente, ele foi o degrau seguinte deliberado depois do Mapa dos Rolezinhos: os mesmos fundamentos de mapa e Firebase, agora elevados a PWA offline-first com login, sincronização em nuvem e uso em condição real de rua.

Problema

Em um bloco com milhares de pessoas, todo mundo disputa a mesma antena. O acesso falha exatamente no momento de maior necessidade: onde é o próximo bloco, vai chover às 16h, onde fica o ponto de encontro do grupo. Um app que depende de rede para abrir vira tela branca no meio da festa. O requisito central, portanto, não era uma funcionalidade — era uma propriedade: a informação precisa estar no bolso, com ou sem sinal.

Usuário

O folião em movimento decide o rolê na rua, com bateria contada e sinal instável; ele precisa abrir o app e resolver em segundos. O usuário recorrente monta a própria agenda de blocos antes e durante o Carnaval e quer vê-la em qualquer dispositivo. Daí a regra de produto: tudo funciona sem conta; o login com Google é opcional e existe para uma única coisa — fazer a agenda seguir o usuário.

Stack

• JavaScript — SPA instalável como PWA; manifest e ciclo de vida controlados à mão.
• Service Worker — app shell e dados em cache para abertura instantânea e uso offline.
• Firebase — Authentication com Google para login e banco em nuvem para sincronizar a agenda.
• Leaflet + OpenStreetMap — mapa interativo dos blocos, reaproveitando a base validada no Mapa dos Rolezinhos.
• Open-Meteo — previsão do tempo por hora, consumida direto do cliente, sem chave de API.

Arquitetura

O Service Worker mantém o app shell em cache: o aplicativo abre instantaneamente, com ou sem rede, e exibe os últimos dados conhecidos. Quando há conexão, o conteúdo é atualizado e o cache renovado em segundo plano. A agenda do usuário nasce local; ao entrar com Google, ela é sincronizada com a nuvem do Firebase e passa a acompanhar o usuário em qualquer dispositivo. A previsão do tempo vem da Open-Meteo diretamente no cliente, e o mapa Leaflet renderiza blocos e pontos sobre tiles do OpenStreetMap. Não há servidor próprio em nenhuma camada.

Funcionalidades

• Instalável na tela inicial, com experiência de app nativo.
• Funciona offline: shell, mapa da última sessão e agenda disponíveis sem sinal.
• Mapa interativo com blocos e pontos de interesse.
• Previsão do tempo localizada via Open-Meteo, hora a hora.
• Login com Google opcional — em um toque, sem formulário.
• Agenda de blocos sincronizada entre dispositivos.
• Interface desenhada para a rua: alvos de toque generosos, hierarquia clara, consumo de bateria contido.

Decisões técnicas

• Offline-first como requisito, não como recurso. O Service Worker trata o app shell com cache-first e os dados com atualização quando há rede. A pergunta de projeto inverteu: não “o que fazer quando estiver offline”, e sim “o que exige rede de verdade”.
• Login opcional e tardio. Exigir conta na entrada mataria o caso de uso principal. O login com Google via Firebase chega apenas quando o usuário quer sincronizar — e, por delegar a identidade ao Google, o projeto não armazena nenhuma senha.
• Open-Meteo em vez de APIs de clima com chave. Em um app 100% client-side, qualquer chave embarcada é pública. A Open-Meteo é gratuita e sem chave, eliminando o problema na raiz — e a resposta horária cabe direto na interface.
• Local primeiro, nuvem depois. O estado local é a fonte primária da agenda; a nuvem é a réplica que dá continuidade entre dispositivos. Essa ordem garante que o app inteiro funcione sem conta e sem rede.
• Base de mapa reaproveitada. Leaflet + OpenStreetMap já tinham sido validados no projeto anterior; reutilizar a dupla liberou o orçamento de risco para o que era novo: Service Worker e sincronização.

Segurança

Os princípios do case anterior continuam: interface não é fronteira de segurança e a configuração do Firebase no bundle não é segredo — as regras do banco são o controle real. O que muda com login e sincronização: os dados da agenda são isolados por usuário, e as regras garantem que cada pessoa lê e escreve apenas o que é seu, validando a identidade autenticada em toda operação. A autenticação delegada ao Google elimina senha própria e reduz o dado pessoal armazenado ao perfil básico. E como o login é opcional, a maior parte dos usuários usa o app sem entregar dado nenhum — a melhor postura de privacidade é não coletar.

Aprendizados

• O ciclo de vida do Service Worker é traiçoeiro: atualização, ativação e caches antigos precisam de estratégia de versionamento desde o primeiro deploy, não depois do primeiro bug.
• Offline-first muda o desenho dos dados: “última versão conhecida” vira cidadã de primeira classe, com a interface deixando claro o que pode estar desatualizado.
• Login opcional é decisão de UX e de segurança ao mesmo tempo: menos fricção na entrada e menos dados sob custódia.
• Testar na rua não é testar no Wi-Fi: o throttling do DevTools aproxima, mas a rede real congestionada de um bloco é outro regime — e foi lá que o offline-first provou valor.

Próximos passos

• Notificações push para mudança de bloco e alerta de chuva iminente.
• Background sync: gravar alterações feitas offline e enviá-las quando a rede voltar.
• Modo pós-evento: histórico dos blocos curtidos como memória do Carnaval.
• Edição 2027 com catálogo de blocos atualizável sem novo deploy.