Reimagining the Iggy Web UI: a zero-friction, "it just works" developer experience

[ryerraguntla]

Why this discussion

Iggy already wins the architecture argument in streaming services: a Rust core, native QUIC/TCP/HTTP/WebSocket transports, a thread-per-core design, and none of the JVM baggage. The web/ dashboard (Svelte-based, shipped as apache/iggy-web-ui) is a solid start for 0.8 — it covers streams, topics, message browsing, and user management. Now with 0.9 VSR support , clustering -
UI for monitoring and navigating for troubleshooting is next milestone.

This discussion is a proposal for where the UI could go next: a design direction, not a spec. The goal isn't to bolt on more panels — it's to make the UI feel as fast and unfussy as the server underneath it. Community's feedback on the direction is appreciated before any of this becomes GH issues/PRs.

The proposal grew out of a comparison of existing streaming services (Kafka suporting services) UI tooling and against where Iggy's UI stands today.

The problem with existing Streaming services UI tooling

What works with current UI tooling :

• Multi-cluster switching, Schema Registry support, free/OSS
• Data masking, responsive live-tail, clean dark mode
• Strong search/filtering, ksqlDB integration
• RBAC, lineage, consumer-lag alerting

Not so great :

• Deeply nested menus, raw JSON walls, admin-tool-from-2012 feel
• Tightly coupled to Redpanda; opaque partition internals
• Steep learning curve; struggles/freezes on very large topics
• Heavy JVM footprint just to run the dashboard

The current streaming services(Kafka based) UIs mirror their operational complexity back at the user — lots of configuration, lots of tables, very little sense of what's actually happening right now. Iggy doesn't carry that legacy weight, so the UI doesn't have to either.

Three principles for the direction

• Zero configuration. If the server is reachable, the UI should be usable immediately — no SASL/JAAS-style setup, no YAML wall before you see your first stream.

• Speed as a feature, not a benchmark. Iggy's server already does sub-millisecond tail latencies over QUIC/TCP; the UI shouldn't be the slowest part of the stack. No spinners on operations that should be instant.

• Progressive disclosure. Show what's relevant right now (streams, live throughput, an obvious search bar); tuck advanced configuration (retention policy internals, partitioning strategy, compaction settings) one level deeper instead of on the landing screen.

**Feature directions **

• Unified command/search bar (Cmd/Ctrl+K).
  One entry point to jump to a stream, topic, or message by ID/key/status, instead of drilling through nested menus. This is the single highest-leverage change for day-to-day debugging.

• Live topology view.
  Streams → topics → partitions → consumer groups rendered as a connected, real-time map rather than a set of disconnected tables, so a stalled consumer or a hot partition is visually obvious instead of requiring you to cross-reference three screens.

• Virtualized message timeline with inline diff.
  Message browsing that stays smooth at high volumes (virtualized rendering, not "load everything into the DOM"), with a one-click diff between two messages — useful for spotting drift or a malformed payload without piping things through an external JSON formatter.

• Transport/telemetry panel.
  Iggy natively supports QUIC and WebSocket, both of which the current dashboard doesn't surface at the protocol level. A lightweight, push-based (WebSocket) panel showing per-partition throughput and transport health would make network-layer issues visible without reaching for external Prometheus/Grafana for the basics.

• Schema/payload impact preview.
  Before a producer-side schema or serialization change ships, show which topics/consumers a sample payload would break — even a minimal version (schema diff + "this field is missing") would beat finding out from a crashed consumer in production.

• Hierarchical navigation for streams/topics.
  A Finder-style, nested view for teams with many streams/topics, instead of one flat list — this is about visual organization, not a change to Iggy's actual (flat) namespace model.

None of this requires abandoning the current Svelte-based dashboard — most of it is additive, and some (virtualized rendering, the command bar) could land as incremental PRs against web/ without a rewrite.

Ask

1. Does this direction match where maintainers want the Web UI to go, or does it conflict with existing plans for web?
2. Which of these should be sequenced first? My instinct is: virtualized message view → command bar → topology view → telemetry panel → schema preview, roughly in order of "smallest lift, biggest daily-use payoff" first.
3. Anyone already working on overlapping UI work I should be aware of, so we don't duplicate effort?

I am not an UI expert to comment on the design and implementation challenges aspect, but I certainly need a monitoring tool with intuitive experience in navigating the clusters and messages in the streams.

[ryerraguntla]

Looks its too early to have a discussion on this. will close for now.