Meliora Mirror: Keeping a Display That’s Always On, Always Fed

Meliora Mirror backend architecture diagram

Data flow from external APIs and sensors through the backend to the on-device display.

Part 1: Introduction

1.1 The Problem

The frontend needed a steady, reliable stream of weather, calendar, transit, and market data, without ever showing a blank widget because an upstream API hiccupped. The backend question wasn’t “how do we call some APIs,” it was how do we keep a display that’s on 24/7 always showing something correct, even when the outside world — networks, third-party APIs, hardware sensors — isn’t reliable.

1.2 Constraints, Stated Up Front

Always-on, unattended. No one restarts the mirror when something breaks. The backend has to recover on its own.
Multiple unreliable upstreams. Weather, transit, stocks, and news each come from a different third-party API, each with its own uptime, rate limits, and failure modes.
Local hardware in the loop. Some data (motion for wake/sleep, ambient light for brightness) comes from sensors attached to the Pi itself, not the network.
One consumer, tight latency expectations. Unlike a typical multi-tenant API, this backend serves a single frontend that expects near-real-time updates without polling aggressively enough to hit rate limits.

Part 2: API & Data Model Design

The backend exposes a small, purpose-built REST API rather than passing third-party responses straight through. Each external source is normalized into a shape the frontend never has to think about the origin of: