Context
Belo Horizonte’s street carnival pulls huge crowds into the neighborhoods — and pushes the cellular network to its limit. This is an independent project, with no brand affiliation or endorsement, built as a companion app for the 2026 edition. Technically, it was the deliberate next step after Mapa dos Rolezinhos: the same map and Firebase foundations, now raised to an offline-first PWA with login, cloud sync, and real street usage.
Problem
In a parade block with thousands of people, everyone competes for the same antenna. Access fails exactly at the moment of greatest need: where the next block is, whether it will rain at 4 pm, where the group’s meeting point is. An app that needs the network just to open becomes a blank screen in the middle of the party. The central requirement was not a feature — it was a property: the information must be in your pocket, with or without signal.
User
The reveler on the move decides where to go while on the street, with limited battery and unstable signal; they need to open the app and get an answer in seconds. The returning user builds their own block schedule before and during carnival and wants it on any device. Hence the product rule: everything works without an account; Google login is optional and exists for exactly one thing — making the schedule follow the user.
Stack
- JavaScript — a SPA installable as a PWA; manifest and lifecycle handled by hand.
- Service Worker — app shell and data cached for instant startup and offline use.
- Firebase — Authentication with Google for login and a cloud database to sync the schedule.
- Leaflet + OpenStreetMap — the interactive block map, reusing the base validated in Mapa dos Rolezinhos.
- Open-Meteo — hourly weather forecasts consumed straight from the client, with no API key.
Architecture
The Service Worker keeps the app shell cached: the application opens instantly, with or without a network, and shows the last known data. When there is a connection, content is refreshed and the cache renewed in the background. The user’s schedule is born local; after signing in with Google, it is synced to Firebase’s cloud and follows the user on any device. Weather comes from Open-Meteo directly on the client, and the Leaflet map renders blocks and points over OpenStreetMap tiles. There is no custom server in any layer.
Features
- Installable on the home screen, with a native-app feel.
- Works offline: shell, last session’s map, and schedule available without signal.
- Interactive map with parade blocks and points of interest.
- Localized hourly weather forecast via Open-Meteo.
- Optional Google login — one tap, no forms.
- Block schedule synced across devices.
- An interface designed for the street: generous touch targets, clear hierarchy, restrained battery use.
Technical decisions
- Offline-first as a requirement, not a feature. The Service Worker serves the app shell cache-first and refreshes data when the network allows. The design question flipped: not “what to do when offline”, but “what genuinely requires a network”.
- Optional, late login. Requiring an account up front would kill the primary use case. Google login through Firebase appears only when the user wants sync — and by delegating identity to Google, the project stores no passwords at all.
- Open-Meteo instead of keyed weather APIs. In a fully client-side app, any embedded key is public. Open-Meteo is free and keyless, eliminating the problem at the root — and its hourly response fits the interface directly.
- Local first, cloud second. Local state is the primary source for the schedule; the cloud is the replica that provides continuity across devices. That order guarantees the whole app works without an account and without a network.
- Reused map foundation. Leaflet + OpenStreetMap had already been validated in the previous project; reusing the pair freed the risk budget for what was new: the Service Worker and sync.
Security
The principles from the previous case still hold: the interface is not a security boundary, and the Firebase configuration in the bundle is not a secret — the database rules are the real control. What changes with login and sync: schedule data is isolated per user, and the rules ensure each person reads and writes only what is theirs, validating the authenticated identity on every operation. Delegating authentication to Google removes custom passwords and reduces stored personal data to the basic profile. And since login is optional, most users run the app without handing over any data at all — the best privacy posture is not collecting.
Lessons learned
- The Service Worker lifecycle is treacherous: updates, activation, and stale caches need a versioning strategy from the first deploy, not after the first bug.
- Offline-first changes data design: the “last known version” becomes a first-class citizen, with the interface making clear what may be outdated.
- Optional login is a UX and a security decision at once: less friction at the door and less data in custody.
- Testing on the street is not testing on Wi-Fi: DevTools throttling approximates it, but the truly congested network of a parade block is a different regime — and that is where offline-first proved its value.
Next steps
- Push notifications for block changes and imminent rain alerts.
- Background sync: record changes made offline and send them when the network returns.
- A post-event mode: a history of enjoyed blocks as a memory of carnival.
- The 2027 edition with a block catalog that updates without a new deploy.