Dashboard for Toxiproxy

[akash-akya]

1. Most of the operations are implemented.
2. Single file
3. Since the dashboard is making requests, I removed the check to determine the browser from the user-agent.
4. Using Statik to embed the HTML into binary

UI might need more refining

[xthexder]

This is awesome! I've wanted a dashboard built-in for a while, but we haven't really had a completed one until now. Tested this out by proxying the dashboard itself and it worked great.

Here's a couple of initial feedback items:

1. Since the root path is currently unused, I think it would make sense to have the dashboard right at http://localhost:8474/
2. Since Statik is another go app, maybe we could add it to the vendor directory so it doesn't have to be user-installed. Currently the only other user-installed dependencies are for release builds only, which makes first time dev setup nice and easy.
3. It might be nice to have this functional if there's no internet connection. I'm not sure if adding the css/js straight to the binary is the best idea, but it's something we should discuss.
4. Proxy enable/disable could maybe use a confirmation dialog when disabling since it's an easy missclick, but I like how easy modifying toxics is with this, especially with it immediately updating the UI with server state (try creating a proxy without the listen address set :+1: )
5. We currently don't have an endpoint to list the available toxic types, but it might be nice to add. I've thought about toxics added in custom builds (or maybe plugins in the future), and it would be nice for the dashboard to support these out of the box. I'll look in to this maybe after this gets merged.

@jpittis @sirupsen Have you got any thoughts on this? I'd love to have this merged.

[akash-akya]

Thanks, @xthexder for your feedback.

Regarding your feedback points,

1. Yes, we could use the root path. If its fine, I'll make changes.
2. I'm new to Go, so I don't know the project structure. I'll look into it.
3. I'm not sure about having js/cs in the binary. I avoided creating multiple files for the same reason.
4. You are right. I'll add a confirmation dialog.
5. An endpoint for Toxic types along with attributes descriptions will be nice to have.

[xthexder]

:+1: for root path

I haven't had to update the vendoring on this project recently, so my knowledge is a little rusty too. It's a code dependency as well, so it will need to be vendored anyway at some point. If you do it, then great, otherwise I could update it after merging.

I think for now the current js/css setup is fine, if we want it work offline, that can be done in a separate PR. I think the same can be said about a toxic types endpoint.

[akash-akya]

Hi @xthexder I made the necessary changes. Also tried vendoring, it did add the statik to vendor, but it is removing some of the existing dependencies from Godeps.json! I'm not sure this correct or not. So can you do the vendoring after merging?

[xthexder]

Thanks for this contribution!

It looks like there's some security issues around Toxiproxy access from a browser, so we're going to have to sort those out before this gets merged. It shouldn't be too hard to fix, but I think we've actually got some issues even in the current release that need to be fixed first.

[jonatan-ivanov]

@xthexder were those security issues sorted out so that this can be merged?

[jonatan-ivanov]

@dianadevasia By renaming master -> main I think you unintentionally closed lots of PRs including this one, see: https://github.com/Shopify/toxiproxy/pulls?q=is%3Apr+is%3Aclosed+sort%3Aupdated-desc

(I think using the rename feature of GitHub would have prevented this.)