server-replay
server-replay copied to clipboard
Sugestions for additional / improved heuristics
I'm using the tool to do record-replay browser sessions. Its great (thanks!)
A couple of ideas for suggestions for better heuristics for which request to return (that would at least be useful in my case, and maybe generally to users of the library):
- Keep track of which responses have already been returned from the HAR, and either remove them from further consideration, or de-prioritize them in the heuristic scoring system
- Keep track of the order that responses have been returned, and prioritize / favor responses that come as-soon after the last returned response as possible (since on replay, responses likely should be returned in the same order)
- Add further debugging information, describing which response is being suggested, and for which reasons.
Are any of the above appealing? If so, I'd be happy to submit PR's for them. Just wanted to get a heads up in if they seem appealing before getting the code ready
https://github.com/Stuk/server-replay/issues/6#issue-308285928 - @snyderp How do I run this software? Explain it to me like I am 5 years old. See https://github.com/Stuk/server-replay/issues/8
Seriously, all readmes should explain things like their audience is a 5 year old, that way there is no room for error. Also I have localhost running with XAMPP and PHP.
@ProximaNova you might want to ask the software author. I'm not in a position to write a guide to someone else's software, but you might find google's catapult / record-replay systems to be a useful (though heavier) alternative.
https://github.com/catapult-project/catapult/tree/master/web_page_replay_go
good luck!