Description
cornerback currently assumes an HTTP-based model for ingestion, replay, and routing. While this works well for traditional webhook providers, many modern systems rely on other asynchronous communication patterns such as message queues, streaming platforms, and persistent connections.
To expand cornerback’s usefulness as a general-purpose event debugging and routing tool, we should introduce an adapter layer for non-HTTP integrations. This would allow cornerback to ingest, replay, and route events across a broader set of systems while maintaining a consistent internal event model.
Examples of integrations that would benefit from adapters include:
- Apache Kafka (distributed streaming platform)
- RabbitMQ (message broker)
- Amazon SQS (managed message queue)
- NATS (lightweight pub/sub system)
- WebSocket (bidirectional real-time communication)
- gRPC (service-to-service RPC framework)
This feature would introduce a generalized Adapter interface that allows:
- Ingesting events from non-HTTP sources
- Replaying events back into those systems
- Routing events between heterogeneous systems (e.g., Kafka → HTTP, WebSocket → SQS)
- Normalizing payloads into a common internal representation
This aligns with cornerback’s goal of being a control plane for event-driven systems, rather than being limited to webhooks.
Acceptance Criteria
-
Define a generic Adapter interface in cornerback-core that supports:
- Event ingestion from external systems
- Event emission (for replay/routing)
- Optional transformation and normalization
-
Support at least one non-HTTP adapter implementation (e.g., Kafka or WebSocket) as a proof of concept
-
Adapters can be registered/configured per “source” or “webhook ID” equivalent
-
Events from all adapters are persisted using the existing EventStore abstraction
-
Replay functionality works across adapters:
- HTTP → Kafka
- Kafka → HTTP
- etc.
-
Provide a configuration mechanism to define adapter types and connection details (e.g., topic, queue URL, endpoint)
-
Ensure adapter failures are isolated and do not crash the core ingestion pipeline
-
Document how to implement custom adapters for additional systems
-
Maintain backward compatibility with existing HTTP webhook ingestion
-
Include examples demonstrating:
- Consuming from Kafka and routing to HTTP
- Receiving HTTP events and replaying to a message queue
Description
cornerback currently assumes an HTTP-based model for ingestion, replay, and routing. While this works well for traditional webhook providers, many modern systems rely on other asynchronous communication patterns such as message queues, streaming platforms, and persistent connections.
To expand cornerback’s usefulness as a general-purpose event debugging and routing tool, we should introduce an adapter layer for non-HTTP integrations. This would allow cornerback to ingest, replay, and route events across a broader set of systems while maintaining a consistent internal event model.
Examples of integrations that would benefit from adapters include:
This feature would introduce a generalized Adapter interface that allows:
This aligns with cornerback’s goal of being a control plane for event-driven systems, rather than being limited to webhooks.
Acceptance Criteria
Define a generic
Adapterinterface incornerback-corethat supports:Support at least one non-HTTP adapter implementation (e.g., Kafka or WebSocket) as a proof of concept
Adapters can be registered/configured per “source” or “webhook ID” equivalent
Events from all adapters are persisted using the existing
EventStoreabstractionReplay functionality works across adapters:
Provide a configuration mechanism to define adapter types and connection details (e.g., topic, queue URL, endpoint)
Ensure adapter failures are isolated and do not crash the core ingestion pipeline
Document how to implement custom adapters for additional systems
Maintain backward compatibility with existing HTTP webhook ingestion
Include examples demonstrating: