Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using "ctx.delay" without arguments should add a realistic server response delay #192

Closed
kettanaito opened this issue Jun 3, 2020 · 7 comments · Fixed by #198 or #205
Closed

Using "ctx.delay" without arguments should add a realistic server response delay #192

kettanaito opened this issue Jun 3, 2020 · 7 comments · Fixed by #198 or #205
Labels

Comments

@kettanaito
Copy link
Member

kettanaito commented Jun 3, 2020

Is your feature request related to a problem? Please describe.
Quite often you would want a mocked response to behave similar to the actual response in terms of response time. Real servers rarely reply to requests instantly, while using res() would do so.

Describe the solution you'd like
Calling ctx.delay() without arguments should implicitly create a random realistic response delay, similar to the one of the actual server.

rest.get('/numbers', (req, res, ctx) => {
  return res(ctx.delay(), ctx.json([1, 2, 3])
})

Possible implementation
Check if the durationMs argument is given to the delay() function:

export const delay = (durationMs: number): ResponseTransformer => {
return (res) => {
res.delay = durationMs
return res
}
}

And if not, generate a random response delay number instead. Something similar to:

res.delay = durationMs || RANDOM_REALISTIC_RESPONSE_TIME
@kettanaito kettanaito added good first issue Good for newcomers feature labels Jun 3, 2020
@UsamaHameed
Copy link

Do we have an idea about what would a realistic response time be?

@juhanakristian
Copy link
Contributor

Maybe something below 100ms would be a good starting point. If the delay range isn't configurable it' probably be a bad idea to set the range too high.

@hehehai
Copy link
Contributor

hehehai commented Jun 4, 2020

Unfixed delay time will increase commissioning costs. This is unknown to the developer.

@kettanaito
Copy link
Member Author

According to this ranking the optimal server response time is ~320ms or less. We can generate a random response time between 100ms (fast) and 400ms (slightly over optimal) to be realistic. Any exceeding response time is considered slow, and should be treated as an issue on the server. We shouldn't ship a slow response time as default, as it effectively means encouraging slow servers.

@andreawyss
Copy link
Collaborator

default delay amount should be very short when running in node vs. when running in browser.
Maybe 10ms and 600ms

@kettanaito
Copy link
Member Author

kettanaito commented Jun 8, 2020

Good point, @andreawyss. I don't think we handled the difference between the browser and Node.

During unit testing, implicit delay shouldn't be in place at all, imho.

@kettanaito kettanaito reopened this Jun 8, 2020
@UsamaHameed
Copy link

I will work on it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants