Great tool! The shell script approach for dynamic responses is really clever - much simpler than spinning up language-specific frameworks. I can see this being super useful in CI/CD pipelines where you need lightweight mocking without dependencies.
This might be a little off topic but since this thread has people interested in SaaS and tech tools, how do you guys launch on Product Hunt? Curious to learn from your strategies.
Interesting, a few questions:
1. 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
2. What's the main motivation for creating this tool? I feel like every programming language have similar tool already - WireMock for Java etc. Why should people switch?
Hi thanks for the feedback checking out the project.
> 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:
> 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.
It frustrates me no end when large commercial web sites fail to store state in URLs. It should be updated when the user clicks the 'submit' button of a page, especially when related to searching.
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.
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.
Swagger is a tool for API design and documentation.
Mock on the other hand is an actual API creation utility with which you can define endpoints, execute some logic for each endpoint and then return some data to the client. There are other similar features which are covered in the user guide.
Mock is not:
- A tool for API Specs or documentation
- A GUI tool.
I admit explaining the usefulness of this tool is not the easiest thing.
Great tool! The shell script approach for dynamic responses is really clever - much simpler than spinning up language-specific frameworks. I can see this being super useful in CI/CD pipelines where you need lightweight mocking without dependencies.
This might be a little off topic but since this thread has people interested in SaaS and tech tools, how do you guys launch on Product Hunt? Curious to learn from your strategies.
Interesting, a few questions: 1. 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 2. What's the main motivation for creating this tool? I feel like every programming language have similar tool already - WireMock for Java etc. Why should people switch?
Hi thanks for the feedback checking out the project.
> 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.
It frustrates me no end when large commercial web sites fail to store state in URLs. It should be updated when the user clicks the 'submit' button of a page, especially when related to searching.
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.
I think you intended to post here: https://news.ycombinator.com/item?id=45789474
I did :) good pick up!
Did you comment on the wrong post? There’s another post talking about storing state in URLs
> Making an existing API slow can be easily accomplished combining mock’s Base APIs and the delay option.
Ah, it's the "billable hours" variable.
Wonderful little tool! Something similar has been swirling aronud my head for a while. Thank you for sharing, it looks very useful.
Hi, thanks for the feedback! I hope it's useful to you.
the name mock has also been used for the RPM build environment tool (https://github.com/rpm-software-management/mock)
Hi, thanks for the feedback!
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.
Does it support Windows? I don’t see a Windows version on the GitHub releases page.
Hi! Not yet, unless you use it with containers.
With wsl (or docker desktop), for non production tooling, I don't think it's relevant anymore.
(I'm not saying it's on par with linux, I'm just saying it's usable)
looks like based on linux is the reason
How does this differ from swagger?
Swagger is a tool for API design and documentation.
Mock on the other hand is an actual API creation utility with which you can define endpoints, execute some logic for each endpoint and then return some data to the client. There are other similar features which are covered in the user guide.
Mock is not: - A tool for API Specs or documentation - A GUI tool.
I admit explaining the usefulness of this tool is not the easiest thing.
Any feedback is welcome!
What a great tool! Writing simple scriptable mock apis all for the command line. Very easy to include commands straight into documentation.