-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add basic KV REST html UI #224
Conversation
This change adds a basic UI for querying the REST API from a web GUI at /kv/rest/. It avoids the external dependency of another file (rest_ui.html) by generating a file through the go generate command and the embedfile tool before compilation. This is all a preamble to a better REST API, but also autogenerated documentation using embedfile and go generate.
something that could also be fun to have is describing our API in something like Swagger, which could enable us to have a fairly flexible frontend for playing around with the api and inspecting things. Maybe from a description of our API we could auto-generate the HTMLs and embed them as you do above. |
@tschottdorf it seems like the docker setup is complaining but I can't see where there would be an issue outside of there not being a proper go dev environment (gocode/bin/ in PATH). Is my hunch correct or is it something else? |
This is what the UI looks like right now: http://cl.ly/image/1Z2d1C2T2O2e |
the problem was that ./bootstrap.sh is not actually run for the Docker builds; the devbase image is created in ./build/devbase and cannot access anything outside of that directory. It would be better to move embedfile out of ./tools into, say, build/devbase/tools, in which case we could install it in godeps.sh instead
test passed now, after the usual gossip cycle failure. I've written a comment in the commit I added, maybe you can do something with it. |
Thanks, Tobias! |
You're welcome. |
As discussed offline, I think we should start a source subdirectory containing html and css and then include those files in the docker container for deployment. We're going to really expand the shape and size of this web app over time so I think we want to get it started with a framework which will make development and eventual scale more tractable. Since you already have lots of experience with Angular and most other people with an opinion have indicated it's probably the right way to go, that'd be my preference. My experience with Ember left a bad taste in my mouth. |
Sounds good. Do we want to use embedfile for certs like @tschottdorf wants? |
It's not immediately relevant. Once we have tests for the UI of course we'll have the same problem again, meaning that we'll find a solution regardless. I think all explicit paths should simply be relative to the location of the main binary (meaning an explitic cwd up from the package in tests that need to reference files). |
@spencerkimball @andybons can you comment on the Swagger idea? I feel like most of the standard API explorer code is already written and we could just save a bunch of time plus enable some other stuff that needs a description of the API. |
For instance, https://www.npmjs.com/package/swagger-angular-client |
I think it’s worth looking into. For the beta I think my time is better spent helping out with Raft, though. In regard to #175, I can write up a wiki page documenting the calls or have something on cockroachdb.org. |
I'm perfectly happy using swagger, though their stylesheet is U.G.L.Y., and it ain't got no alibi. But swagger is just a piece we put in on top of a single page JS frontend app. Like plottable or C3 for charts. There'll be many others. |
PTAL. Full Angular goodness. |
</head> | ||
<body> | ||
<header class="appNav"> | ||
<a href="#/" class="appNav-link appNav-homeName">Cockroach</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see playground as being an ancillary feature. I think index.html should be immediately at the status page for the cluster as a whole.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it's just a blank page. The only UI that actually exists is the rest explorer.
LGTM and am really happy to get a start on an admin UI. I agree with Tobias that we should integrate with Swagger. |
@tschottdorf do you think it’s worth putting /static within /resources? They both seem to serve the same purpose as non-go source files, but I could go either way. |
I think we should create a new source directory for all of our javascript frontend code. /resources is more for non-code items. HTML and CSS are definitely source code. Here are some possible names for this directory: /frontend |
I like ui. Short and sweet. |
Cool, let's do it. |
This change adds a basic UI for querying the REST API from a web GUI at /kv/rest/.
It avoids the external dependency of another file (rest_ui.html) by generating a
file through the go generate command and the embedfile tool before compilation.
This is all a preamble to a better REST API UI, but also autogenerated documentation
using embedfile and go generate.