Roadmap#
Junction ships as 0.x.x with an unstable /v0 API contract. The items below are what’s planned before that contract stabilizes at 1.0.0//v1, plus everything queued up after.
Before 1.0.0#
-
Trace ID propagation to destinations — outbound delivery requests carry the trace ID as anX-Junction-Trace-IDheader, shipped inhttp-destination0.2.0 -
Integration testing — full HTTP request cycle, repository SQL, and migration correctness verified end-to-end by a test suite covering every endpoint across all resources - Enhanced exception handling & response messaging — most unanticipated errors currently fall through a single catchall handler and return a generic
JUNCTION_0000/500, which masks the actual problem from the caller. Needs targeted exception handling with accurate status codes and messaging so callers get an explanation they can act on. See Errors . - Advanced sorting & filtering on log records — sort event logs by receipt time, filter by trace ID; sort/filter destination delivery history by attempt time and status
- Serializer meta links — embed canonical URLs to related resources in responses (e.g. a destination response linking to its destination type)
- API versioning graduation — rename
/v0routes to/v1across the API, workers, and CLI once the contract is considered stable
Post-1.0.0#
- Extract common destination worker components for reusability — registration (
PUT /system/destination-types/registeron startup) and status-queue production (junction.status) are currently reimplemented per worker; pull them into a shared library so a new destination type only has to implement delivery, not the boilerplate around it - Worker heartbeat — workers send a periodic beacon to a dedicated queue; the system worker tracks last-seen per worker ID and surfaces a worker as down once it exceeds a missed-heartbeat threshold. Adds operational visibility without needing cluster access.
- Sort destinations by status
- Redis query cache — only if read-volume performance warrants it; not needed at current scale
Known technical debt#
- Manual relationship loading — destination/event relationships are loaded and mapped by hand in a few request handlers rather than through a native relational query layer. Planned fix is at the data-layer level, not by adding application-side abstractions.
Adding a destination type#
Junction ships with one destination type — HTTP. The worker contract is open: implement a worker that consumes from its own queue, delivers to its target, registers its destination type with the API on startup, and reports delivery status back. No API or schema changes required. See Components and System .