Ah, it's the "billable hours" variable.
Some products have these fancy KQL style search parameters but if you forget to 'save the search' within the applications 'Save Search' facility, then when you duplicate a tab the search is lost.
It feels rude when sites ignore the UX improvement by not leveraging the power of URLs to store current state.
> What's the main motivation for creating this tool?
Similar tools exist out there for sure, but they are either complex (more than I wish they'd be) or somehow require you to use a specific programming languages. Mock lets you accomplish this without telling you which language you should use.
Also if you're using mock inside CI pipelines, it also helps the fact that you can just download a executable tool that does not require you the java platform or any other dependency.
> How hard/easy is it to make responses dynamic, i.e. to use something from the request data like query/path param or a body to execute function instead of hardcoding the response
With mock you can use shell scripts as "request handlers". With that said, capturing a query param or a JSON field from the request body is as simple as:
> $ USER_NAME=$(mock get-payload user.name)
> $ SOME_QUERY_STRING_PARAM=$(mock get-query foo)
You can see more of this topic here: https://dhuan.github.io/mock/shell_scripts.html
> I feel like every programming language have similar tool already - WireMock for Java etc. Why should people switch?
True. If people are happy with these tools and needing to use java (or any other lang the tool pulls you into), then there's not much reason to switch.
(I'm not saying it's on par with linux, I'm just saying it's usable)
That's true, it's not a very unique name. I started building it, but only months later I thought of making it public. And then never thought of renaming it.
Making an existing API slow can be easily accomplished combining mock’s Base APIs and the delay option.
$ mock serve -p 8000 --base example.com --delay 2000
You may want however to make a specific endpoint slow instead of the whole API. This can be achieved using middlewares:
$ mock serve -p 8000 --base example.com --middleware ' if [ "${MOCK_REQUEST_ENDPOINT}" = "some/endpoint" ] then sleep 2 # wait two seconds fi '
With that last example, our API at localhost:8000 will act as a proxy to example.com. All requests will be responded immediately except some/endpoint which will have a delay of 2 seconds.
Let’s test it:
$ curl localhost:3000/js # Prints out: Hello from Node.js! $ curl localhost:3000/python # Prints out: Hello from Python! $ curl localhost:3000/php # Prints out: Hello from PHP!
$ export TMP=$(mktemp) $ printf "0" > "${TMP}"
$ mock serve -p 3000 \ --route '/hello' \ --exec ' printf "%s + 1\n" "$(cat ${TMP})" | bc | sponge "${TMP}"
printf "This server has received %s request(s) so far." "$(cat '"${TMP}"')" | mock write '
Let’s test it:
$ curl localhost:3000/hello # Prints out: This server has received 1 request(s) so far. $ curl localhost:3000/hello # Prints out: This server has received 2 request(s) so far. $ curl localhost:3000/hello # Prints out: This server has received 3 request(s) so far.