Is there a Web UI on the roadmap by any chance?

[andy-g]

Is your feature request related to a problem? Please describe.
Our current development environment is dockerised, and dev's will bring up the stack using docker-compose. We can easily add mockoon to the docker-compose file, but without installing the full mockoon, developers will not be able to use the UI to view the logs, and to disable routes and allow proxying of requests etc.

Describe the solution you'd like
It'd be amazing if this functionality could be available via a web ui (similar to https://www.mock-server.com/mock_server/mockserver_ui.html), so a developer could clearly see what requests / responses are being mocked, and ideally be able to disable the mocked route, bring up the required backed server, and then see the logs for the actual calls - and then ideally have the option to save the response as a mock - as you can in the current desktop UI.

Describe alternatives you've considered
As mentioned above, mock server allows for this via their web based dashboard, but your UX / UI is a wold ahead of that.

I've just stumbled across mockoon today, and really been impressed by what I've seen and been able to play with. Thanks so much for what you've built, I'm keen to take a closer look at how we can use it in the future.

[255kb]

There is currently no UI for the CLI as it was rather built as a companion to the desktop app, than as a standalone tool.
However, this is not the first time this was suggested. So, we may add this in the future.

[andy-g]

Thanks for the feedback, yes, I realise that it doesn't make sense to add to the cli, the reason I posted it here was the CLI runs nicely on docker, and I'd love to have closer to the full mockoon experience in a docker-compose environment using a web UI.

Happy for you to close this issue, was just really excited to see what you've built and thinking how it would fit into our development processes.

[255kb]

Let's keep the issue opened for a while to see if there is more interest.
On the desktop side, some "admin" API has also been requested.

If this kind of feature would be added it could take multiple form, but I see two interesting things:

• an API to programmatically query what is happening inside the CLI or the desktop UI
• a way to control CLIs or deploy Docker containers from the UI

[bewareilive]

I have an idea.
The real reason people want the web version is because they want to modify the configuration on CLI (usually on the server). Copying the config file to the server is more of a hassle.

Then could you add a function on the client for pushing and downloading config files to the server, and open a send/receive interface on the CLI , while updating the service after receiving the config.
Or other ways to edit configuration files remotely using the client.

developers don't have to maintain the Web ui, CLI size does not become large, And solves most user needs

[kajweb]

I have an idea. The real reason people want the web version is because they want to modify the configuration on CLI (usually on the server). Copying the config file to the server is more of a hassle.

Then could you add a function on the client for pushing and downloading config files to the server, and open a send/receive interface on the CLI , while updating the service after receiving the config. Or other ways to edit configuration files remotely using the client.

developers don't have to maintain the Web ui, CLI size does not become large, And solves most user needs

If editing locally, I think an important issue is how to solve the problem of delay. #681

[itviewer]

A Web UI can greatly facilitate team collaboration. It would be more convenient if the routes could be grouped instead of running multiple environments.

[bewareilive]

A Web UI can greatly facilitate team collaboration. It would be more convenient if the routes could be grouped instead of running multiple environments.

Two of the most frequently issues: WebUI and Save parameters

[m-roberts]

I have an idea. The real reason people want the web version is because they want to modify the configuration on CLI (usually on the server). Copying the config file to the server is more of a hassle.

Then could you add a function on the client for pushing and downloading config files to the server, and open a send/receive interface on the CLI , while updating the service after receiving the config. Or other ways to edit configuration files remotely using the client.

developers don't have to maintain the Web ui, CLI size does not become large, And solves most user needs

What I am imagining when I read this is that the hard-coded 0.0.0.0 of the current app becomes something that can be pointed to a remote server (incl. a locally-run Docker service with a different hostname). The start/stop server button can be extended to also include "remote connect" functionality, but there would also need to be a way of disabling remote environments that we might want to keep around but aren't actually "up".

Under the hood, you just stream the incoming log data (useful for mocking from recorded requests) and the obvious outgoing config changes as if it were running locally. When the connection drops, either display an error or automatically disable the service.

With this implemented, additional documentation can be added providing instructions for remote debugging, docker-compose development, etc.

Would absolutely love to see this! This is a really great tool at it is, but being able to use it in a docker-compose development workflow would be a dream.

[aaroneva43]

Would love the have WebUI :). I personally do VScode remote-ssh and have to open up an RDP window for mock data editing. I could mount the remote directory and edit the config file locally, yet I do not get the full functionalities like Logs and the mock server won't auto-restart.

[jiteshgolecha]

+1

[nf-ssc]

Would also love to see the desktop app as a dockerized web-ui which I can then add to my docker-compose file in Codespaces/Devcontainers much like the PGAdmin Docker image (dpage/pgadmin4) to manage my (also dockerized) Postgres DB. With such a solution we would not have any dependencies to preinstalled tools on a developer's laptop (which might be restricted anyway) and could set up all our mocked API instances automatically. The whole setup would live inside containers.

You could expose the Desktop UI on one port of the container and the mocked API on another port and keep the rest as it is now :)