Ember — event discovery on a fleet of Raspberry Pis
Finding out what is on in a city means scraping a lot of places politely. Ember does it from a fleet of small edge workers that submit signed batches to a Django backend, which stays the single system of record and publishes nothing without review.
Ember
Ember is an event discovery product: a Flutter app, a Django backend, and the thing that keeps them fed — a scraper fleet.
Local-first workers
The fleet is designed to run on a laptop first and Raspberry Pi edge devices after, collecting raw, source-shaped records at a deliberately conservative rate. Eight sources are registered — Eventbrite, Ticketmaster, Meetup, Klook, OpenStreetMap, Reddit, Telegram and RSS — and a source whose credentials are missing skips cleanly rather than failing the run. One make e2e target plans the work, scrapes every source, writes the batch and submits it.
One system of record
Workers never write to the database. They submit signed batches to an ingestion endpoint, and the backend keeps the raw payload before it does anything else: post-process into candidates, deduplicate, enrich, then hold for review. Nothing reaches the app without passing through that queue.
That split is what makes the fleet disposable. A device can be reflashed, moved or lost without taking any state with it, and a parser bug can be re-run against payloads that were already captured.
Backend
Django REST Framework for auth, account management and profiles with interest tags, with Celery handling activation email out of band — Postgres, Redis and the gateway all under Docker Compose, migrating and seeding themselves on first run.