Dashboard Mirror: one page for every service I use

Around the widgets there is the usual product surface: multiple dashboards, drag and drop, a full-screen mode, a shareable view, and export or import of a dashboard configuration. An in-app bell and optional browser push tell you when a widget changes.

Architecture: only the frontend is public#

The browser never talks to a backend service. The Next.js app acts as a backend-for-frontend and reaches three services through an internal Traefik gateway.

Each service owns its own PostgreSQL database, and Redis carries pub/sub, presence, replay buffers and the BullMQ queue. Tokens are verified locally: authentification publishes a JWKS, so core and streaming never call back on each request.

Accounts are linked from the Providers page. Several accounts per provider are allowed, and the widgets that need no account, such as weather, RSS or the transit ones, are listed as built in.

How an update reaches the screen#

Every change goes through the same pipeline, whether it comes from a poll or a webhook. The result is diffed against the widget's last value, stored if it changed, and published as a widget.updated event.

1. Collect

   A BullMQ job polls the source at the widget's TTL, or the source calls a signed webhook on core.

2. Diff and store

   applyWidgetUpdates() compares with lastValue. Nothing changed means nothing is published.

3. Publish

   The event goes on Redis pub/sub, and streaming relays it over Server-Sent Events to every open tab.

4. Replay

   Each event has an id, so a browser that reconnects sends Last-Event-ID and gets what it missed.

SSE was enough here because traffic only flows server to browser. It reconnects on its own and goes through the Next.js proxy without any special handling.

Adding a widget is one file#

The part I like most is that the scheduler knows nothing about GitHub or the weather. A source is a provider class, and the generic infrastructure only talks to its contract.

A pollable provider implements listUnits, fetch and diff. A pushable one implements verify, parse, match and reduce for its webhook. YouTube does both: WebSub push, with polling as a fallback for users without an active lease.

listUnits also deduplicates. Several widgets pointing at the same feed become one fetch unit, so the external API is called once and the result fans out to all of them.

Decisions that paid off#

The backend stack came out of a written comparison between Hono with Prisma, FastAPI, Rails, Go and Express, scored on team experience, ecosystem, real-time fit, Docker complexity and long-term risk. Shared TypeScript types between front and back, and a first-class SSE helper, decided it.

The same habit applied to smaller choices. For the ICS widget I benchmarked two parsers on a 397 KB synthetic school planning with recurring events and exceptions, then picked ical.js because it has no dependency and gives the same instants on any machine.

Running it yourself#

The whole stack starts from Docker Compose, and the app is then available on port 8080.

Sign up first, promote that account to admin, then create the service accounts so the services can call each other. After that, link your providers and open the gallery with the Add a widget button to pick one.

What's next#

The provider contract is stable enough that the next widgets are small. The open points are mostly operational: revoking push subscriptions when a user unlinks an account, and creating GitHub webhooks automatically instead of by hand.

• Next.js
• React
• Tailwind CSS
• Hono
• Prisma
• PostgreSQL
• Redis
• BullMQ
• Traefik
• Docker