Add support for slow responses about dev-proxy HOT 16 CLOSED

Just want to add that we should think about the supporting documentation for this in the spec so we don't forget about how to articulate this new feature to our audience. At minimum I think we should provide a How-to guide and update the technical reference.

from dev-proxy.

This isn't really about the network speed, which developers can simulate using browser tooling. This is more about the delayed response from the server, which would occur when the server is under load and it takes a while to process and respond to a request, before it's sent over the network.

from dev-proxy.

Great idea @waldekmastykarz I like this idea a lot, when working with asynchronous code we cannot assume that calls are always timely, or consistent.

Maybe we could provide some preset values here, similar in the way that Dev Tools does to mimic different network conditions, where they provide Slow 3G or Fast 4G profiles (https://developer.chrome.com/docs/devtools/network/reference/#throttling).

I could see this help with scenarios where apps are used on mobile devices away from the office and developers want to recreate those conditions.

from dev-proxy.

--min-delay and --max-delay seem like good candidates with --slow-responses using the min and max delay defaults that are in the appsettings.json file?
providing either --min-delay or --max-delay will enable slow response mode and use the default for the unspecified value

from dev-proxy.

Updated spec. Have I captured everything correctly @gavinbarron?

That captures everything correctly from my point of view.

Is there a reason where we specify the minDelayMs?

I assume you're meaning the Ms suffix on these settings? IMO when reading the code inside the proxy that uses this setting it would also have the Ms suffix and make it more apparent what units the delay is in without the need to change to using jsonc and it's would also be visible in the C# code in this form.
I'm all for eliminating things that don't have value, but keeping the affordance of settings high through convention based naming is a nice thing to me, I hate to have to go look for documentation to for the units of time being used in these scenarios.

from dev-proxy.

@gavinbarron @sebastienlevert @garrytrinder I'd appreciate your feedback on this feature

from dev-proxy.

I feel this should be a little bit more "randomized". Do we have specifics on the endpoints / use-cases that this could deliver? I don't know if we could fake slow responses as it could be slow 2 times (the artificial delay we would add, and then the workload taking extra time). I'd love to understand some of the developers pains you see with this option.

from dev-proxy.

The main scenario for this feature is to help developers understand how their app will look like, when the response from the API isn't instantaneous: will the app be blocked and show an empty page until all requests complete, will there be content shifts that have a negative impact on the UX, etc. I also wonder if there are apps that assume that a request completes within a given timeframe and fail the request when it doesn't to avoid being locked for too long.

from dev-proxy.

Could we also add an optional minimum delay to the parameter e.g. --slow-responses and --slow-responses 2000 are valid but the second ensures a minimum of 2000ms delay is added to responses?

from dev-proxy.

Could we also add an optional minimum delay to the parameter e.g. --slow-responses and --slow-responses 2000 are valid but the second ensures a minimum of 2000ms delay is added to responses?

It's a good idea to offer the ability to specify a minimum value @gavinbarron. How could make it less ambiguous if the specified value is the exact delay, the minimum or the maximum?

from dev-proxy.

Are the min and max values something you'd be likely to change on each proxy run and hence something we should expose as options, or it's rather something you'd configure once in appSettings and then use as your preferred values? Trying to think if we have to add two more options or if a config setting be sufficient.

from dev-proxy.

In my mind they're likely something that I'd put in config as defaults and then be able to override as a command line option.
However being able to override from the command line is a nice to have.

from dev-proxy.

Updated spec. Have I captured everything correctly @gavinbarron?

from dev-proxy.

Is there a reason where we specify the minDelayMs? I don't think it's required and should be documented (Maybe using JsonC in the config file, and in our docs). I don't feel it adds value.

from dev-proxy.

@gavinbarron is right @sebastienlevert. The idea is, that when you're looking at settings you immediately know which unit we expect the value to be in, without having to second guess it/look up in docs/rely on editor features such as intellisense that you might not have. Basically it's aiming to make it self-explanatory.

from dev-proxy.

Completed in #321

from dev-proxy.