Feature: Sessions/Tapes
- Dominant language
- JavaScript
- Stars
- 11
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
## Why
Users should be able to record all traffic for under a specific `session` key, then pick a `session` recording at a later point.
## What
- Build a server api to handle `session` recording (start/stop) and playback (start/stop)
- Build in UI support to call these APIs
Difference in behavior for a `session` vs basic jambox functionality:
- A `session` should only record requests when prompted, no recording of requests during playback of any kind
- A `session` should record all requests as unique entities, recorded chronologically. Should perform no hashing/de-duplication. It's possible this may be configurable in the future.
Consider calling `session` a `tape` to match the theme of a jambox being another name for a boombox.
Contributor guide
Research direction
Start by tracing the existing server API and UI support for basic jambox recording and playback. Clarify the session or tape lifecycle and how recordings are stored before changing either side. Done means start/stop recording and playback work through the UI, with chronological unique requests and no recording during playback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- api, full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100