HN user
I have been working on two opensource tools:
https://dhuan.github.io/mock/latest/examples.html Command line utility that lets you build APIs with just one command.
https://github.com/dhuan/dop JSON/YAML manipulation with AWK style approach.
well done! wouldn't it nice if something like this existed in Lua as well (or maybe it does and I haven't seen it yet)?
I've built a data transforming tool powered by Lua[1] and would definitely like to benefit from an general purpose api/library like Lute.
I have been working on two opensource tools:
https://dhuan.github.io/mock/latest/examples.html
^Command line utility that lets you build APIs with just one command.
^JSON/YAML manipulation with AWK style approach.
I have been working on two opensource tools:
https://dhuan.github.io/mock/latest/examples.html
^Command line utility that lets you build APIs with just one command.
^JSON/YAML manipulation with AWK style approach.
For me it has to be mock. With it I can create and automate APIs easily.
I agree, even trivial tasks require us to go back to jq's manual to learn how to write their language.
this and other reasons is why I built: https://github.com/dhuan/dop
mock, an API creation and testing utility. Any feedback is welcome.
mock, an API creation and testing utility. Any feedback is welcome!
I’ve found tools like Charles really useful for understanding what’s happening on the wire. When I need something more repeatable (tests, offline work), I usually reach for a mock server instead. I ended up building a small one for my own use and later open-sourced it:
mock, an API creation and testing utility. Any feedback is welcome!
Great article. In addition, updating your mocking code can often be time-consuming. To try to make this easier, I built mock[1], which streamlines the process of setting up mock services for testing.
mock, an API creation and testing utility. Any feedback is welcome!
It's also possible create an HTTP service that acts as a wrapper to yt-dlp with just a few lines of shell, I created this example in the following link:
https://dhuan.github.io/mock/latest/examples.html#youtube-do...
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!
I think you intended to post here: https://news.ycombinator.com/item?id=45789474
Hi! Not yet, unless you use it with containers.
Hi, thanks for the feedback! I hope it's useful to you.
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.
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.
I've been working on mock: https://dhuan.github.io/mock/
the process of creating APIs for testing and automation should be as easy possible. the tools that exist nowadays aren't good enough, they require you to use their programming language of choice or complex procedures for a task that should be simple. I built mock to try to solve that and still continue to maintain it.
I've been working on mock: https://dhuan.github.io/mock/
the process of creating APIs for testing and automation should be as easy possible. the tools that exist nowadays for this purpose aren't good enough IMHO, which led me to build it.
I've been working on mock:
the process of creating APIs for testing and automation should be as easy possible. the tools that exist nowadays aren't good enough, they require you to use their programming language of choice or complex procedures for a task that should be simple. I built mock to try to solve that and still continue to maintain it.
that's a really useful testing strategy. I used to to write automated tests using an approach very similar to yours, but I was often bothered that I needed to write code in a programming language to set up the mocked data. After a while the testing code gets really verbose. Not just the mocking setup but also the assertion logic. I wanted an easier way that didn't involve writing much code, so I ended up building "mock":
I built mock, an api tool and testing utility to be able to quickly manipulate API responses and act as a proxy server at the same time.
After some time, I decided to open-source it:
Hey very useful app, I'll be watching this. I once wanted to set up backend apps during automated CI jobs in order to facilitate e2e tests and ended up making an utility kind of similar - but yours truly goes beyond.
With mock you can set up backend APIs completely from configuration files or even from command-line parameters - such as
$ mock serve --port 3000 --route 'say_hi/{name}' --method GET --response 'Hello world! My name is ${name}.' --route "what_time_is_it" --method GET --exec 'printf "Now it is %s" $(date +"%H:%M") > $MOCK_RESPONSE_BODY'
mock - language agnostic API mocking and testing utility https://github.com/dhuan/mock
I built it because I needed an easy way to set-up API endpoints that weren't implemented yet by some other team. After a while I open-sourced it.
wikicmd https://github.com/dhuan/wikicmd
Navigating through mediawiki to get pages edited all time requires a bunch of clicks. I wanted to be able to quickly edit wiki pages using any editor program instead of the browser.
Language-agnostic API mocking and testing utility
Makes sense. Thanks for the suggestion. Indeed it'd be convenient to have that one day.
No, I didn't think of that yet. But yes I can see the benefit. The thing is that Mock's endpoint configuration format enables you do custom things that afaik OpenAPI wasn't designed for. In Mock's endpoint configuration you can set routes to return different responses based on conditions - say if route such was requested with querystring values such and such, then such response would be returned, and so on.
Imagine for example mocking MediaWiki's API where you have a single "api.php" endpoint, where you determine the "action" of the API operation with querystrings. Mock was used here to mock their API enabling me to easily do E2E tests: https://github.com/dhuan/wikicmd/blob/master/tests/e2e/mock/...
One key motivation for building this was that, despite there being other similar tools out there, I wanted a utility that was language-agnostic, meaning I could make test assertions without having to write in some particular language. So Mock was designed this way where assertions are made by simply doing HTTP calls. Another point was installation - setting up Mock in your CI is a matter of just downloading the executable file, where other alternatives required me to install Java SDK, or Nodejs, or whathever programming language their utility was written in, resulting in CI scripts more complicated than what I wanted.