Ability to choose probability of each response when using random responses

[maillouxc]

I have a need to simulate an error which occurs very infrequently. The random response feature is very useful, but I'd really like to be able to adjust the probability of each response.

[glaucoleme]

I think that this feature is related with chooseResponse function, between lines 49~53. I did a draft just to try out a solution of how use the probability of each response could be implemented.

But how this would work? Should an option be added at settings of each response to adjust this probability, which is enabled only when random response mode is activated?

Also, the probability of all responses should sum up to 1 (100%), right? This seems a quite tricky, as more responses are added, all remaining responses probability are affected too. On other hand, without normalizing these scores, it might be confuse for user to handle it.

Just trying to contribuite into the discussion.

[maillouxc]

I think to get around the problem of having to make all the probabilities add up to 100 (which would be quite tricky to implement without a UI redesign) we could instead use weights, which would only be applied if the random response mode is chosen. You would specify a weight value for each response. That is, a response with a weight of 2 should appear twice as often as a response with a weight of 1. Therefore percentage could be (responseWeight / sumOfWeights).

I think as far as how to specify it, whenever the random response mode is enabled, a new small box would appear on the dropdown next to each response that can be sent where you can type the weight.

[glaucoleme]

"Therefore percentage could be (responseWeight / sumOfWeights)."

That is also what I aimed at the draft. Normalizing the values and then compare with random output. This code is badly made, as I did not have time to optimize it. But could you check if its propose fits what you thought?

[255kb]

I'm not sure if many people would use this feature it seems quite specific.
I don't want to add it to the UI and clutter it even more without having some popularity signal (i.e. issue upvotes).

I could settle on adding this feature to the response settings:

As per the implementation, I guess it would be simpler by adding weights to the responses like @maillouxc suggested:

• One input field per response, default to 1 (field could be empty to avoid any confusion)
• in the chooseResponse function we could create an array containing the responses UUIDs, and do the random on the length:

Example: if we have two response, one weighted 1 (default) and the other 2, we would have this array:
['uuid1', 'uuid2', 'uuid2'] and keep the rest of the code nearly unchanged.

[glaucoleme]

I do agree with the popularity signal, but how exactly does this works?

Also, the array ideia is way simpler than the approach I thought at first. Nice call! =]

[255kb]

I do agree with the popularity signal, but how exactly does this works?

It's a bit off topic, but to answer your question it's not an exact science. Usually I look at the issue upvotes (👍), and other activities like comments. But I also listen to the users feedback and support requests. For example, the recent CRUD endpoints weren't subject of an open issue, but this was the biggest misconception in support requests. Lots of people expected it to work like that. So, I decided it was important. It's also a good feature making Mockoon a more serious competitor.

I add to that a bit of "this would make sense", "this is a quick win and could be interesting", "this is highly upvoted but would take a lot of time", etc.
A good example for the latter is the graphQL issue. The most upvoted, with no interaction whatsoever. I asked multiple times in the past for feedback as I don't work myself with graphQL and I got close to 0 replies. Also, this feature is wildly different from the REST approach and requires a lot of changes to the UI.
I did a POC which is more or less working, but realized that it needed some persisting storage. That's why I worked on the data buckets first.
It will probably come but I can only tackle one thing at a time. I try to do my best to find the right balance and also doing all the other stuff to make the project growth (tutorials) and sustainable (Pro plans).

I hope this answers your request!

I am also completely open to feedback, advice and help of any kind 😄