Web CRUD interface

[nbry]

Description

cornerback currently operates as a backend-focused service with API-driven interaction for ingesting, inspecting, replaying, and routing events. While this is powerful for programmatic use, it lacks a user-friendly interface for exploring and managing events in real time.

To improve usability and adoption, we should introduce a web-based CRUD interface that allows developers to interact with cornerback through a browser. This UI would provide visibility into incoming events, replay history, routing configurations, and adapter behavior without requiring direct API calls.

The web interface should act as an operational dashboard for both local development and deployed environments, enabling faster debugging, easier inspection, and more intuitive control over event-driven workflows.

Core capabilities of the UI should include:

• Viewing and searching stored events
• Inspecting full payloads (headers + body)
• Replaying events to configured or custom destinations
• Managing routing rules (fan-out destinations)
• Viewing replay logs and delivery outcomes
• Monitoring failed events and DLQ entries
• Managing adapters and integrations (future)

This aligns with cornerback’s goal of being a control plane for event-driven systems, providing both programmatic and visual control over event lifecycles.

Acceptance Criteria

• Provide a web server (or embedded UI) accessible via browser (e.g., http://localhost:8080/ui)

• Implement CRUD operations for events:

  • List events with filtering (by webhook ID, time range, status)
  • View individual event details (headers, body, metadata)
  • Delete events (optional, configurable)

• Implement replay functionality via UI:

  • Replay an event with default routing
  • Override destination endpoint
  • Display response status and body

• Provide visibility into replay history:

  • List replay attempts per event
  • Show success/failure status and timestamps

• Implement routing management UI:

  • Create/update/delete routing rules per webhook ID
  • Configure multiple destinations (fan-out)
  • Enable/disable routes

• Provide DLQ visibility:

  • List failed/invalid events
  • Inspect failure reason
  • Replay or reprocess DLQ events

• Ensure UI updates reflect real-time or near-real-time event ingestion (polling or websocket-based)

• Maintain separation between API and UI layers (UI consumes public API)

• Ensure the UI works in both:

  • Local development environments
  • Deployed/self-hosted environments

• Provide basic styling and usability (does not need to be fully polished, but should be functional and intuitive)

• Document how to enable and access the UI

• Ensure backward compatibility with existing API-only workflows