Nexus

A local-first developer dashboard that aggregates GitHub, LeetCode, and fitness activity into a single view.

Nexus is built around a simple idea: personal productivity data should be useful without requiring a hosted service or constant tracking.

Nexus was the second step after MCP V1, where I moved from understanding MCP itself to applying the architecture to a practical data aggregation system.

The application runs locally, uses independent MCP providers for each data source, stores historical snapshots in SQLite, and optionally uses a local Ollama model to generate a daily brief.

The idea

Each data source runs as its own MCP server and communicates with the backend through the MCP stdio transport.

The FastAPI layer aggregates the results and exposes a single /summary endpoint to the frontend.

Why MCP providers?

I could have implemented each integration as a normal Python module, but I wanted to explore the separation between data providers and the application consuming them.

Each provider is isolated from the others:

GitHub Provider ──┐
LeetCode Provider ├──> FastAPI ──> Dashboard
Fitness Provider ─┘

A failure in one provider does not prevent the others from being queried. Instead, the backend returns provider-level status and error information so the frontend can distinguish unavailable data from zero activity.

This also makes adding another provider relatively straightforward.

Snapshot history

Successful provider responses are stored in SQLite:

metric_snapshots
├── source
├── captured_at
└── data

The history currently serves as the foundation for future trend visualizations.

Optional local AI

Ollama is used to generate a daily summary from the aggregated activity.

The AI layer is intentionally optional. Nexus remains fully functional when Ollama is disabled.

I also constrained the prompt to avoid generic productivity-coach responses and instead produce short, analytical observations based on the actual data.

Daily briefs are cached so the model is not called repeatedly during normal dashboard usage. A manual refresh endpoint is available when a new brief is needed.

What I learned

The most useful lesson from Nexus was that external services should be treated as unreliable inputs rather than guaranteed dependencies.

Instead of allowing one provider failure to turn the entire dashboard into an error, provider failures are represented explicitly in the API response.

I also learned more about:

• Designing independent MCP providers
• Local AI integration with Ollama
• Persisting historical snapshots
• Building resilient aggregation layers
• Keeping AI functionality optional rather than making it a hard dependency

Current status

Active

Nexus currently supports:

• GitHub
• LeetCode
• Fitness data
• Independent MCP providers
• SQLite snapshot history
• Optional local AI briefs
• React dashboard
• Tauri desktop variant

The next improvements are primarily concurrent provider execution, additional data sources, and exposing the existing snapshot history through trend visualizations.

Repository