Thank you for submitting! Author here :)<p>Feel free to ask any questions. To add full context, based on the all positive feedback i decided to work on Gor full time <a href="https://medium.com/@buger/working-on-open-source-full-time-as-indie-developer-3693fc90d545" rel="nofollow">https://medium.com/@buger/working-on-open-source-full-time-a...</a><p>Thank you! Ready to answer any questions.
This tool reminds me of Raymond Chen's (The Old New Thing) blog post "Microsoft corporate network: 1.7 times worse than hell". The network traffic on Microsoft's (1996) corporate network was 1.7 worse than Microsoft's Windows Hardware Quality Labs own network card stress tests. Network hardware that passed the stress tests would commonly fall over when it was plugged into the corporate network. :)<p><a href="https://blogs.msdn.microsoft.com/oldnewthing/20050512-48/?p=35653" rel="nofollow">https://blogs.msdn.microsoft.com/oldnewthing/20050512-48/?p=...</a>
I have used Gor lots of times before and when I got into Go it was one of the first source codes I looked at.<p>I love seeing open source projects developing a "Pro" version. I've been using Sidekiq Pro for a long time now and I know for sure it won't be as heavily maintained as it is without the Pro option.<p>As far as Gor goes, when you develop a new feature, it's a really powerful tool to pass some of the production traffic to staging to see how the new feature reacts with real world traffic. It's a sure way to find bugs you usually miss with testing.
I'm looking for a sort of reverse solution for 3rd party APIs where you record a response to a request and generate a server with the same API endpoints that'll replay it.
Great tool - we used gor on our team recently to test a rewritten legacy API with captures of real production data. It was invaluable for exposing edge cases in the requests that we hadn't considered.
alt <a href="https://github.com/session-replay-tools/tcpcopy" rel="nofollow">https://github.com/session-replay-tools/tcpcopy</a>