Skip to content
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

Merged
merged 11 commits into from
Dec 18, 2014
Merged

Add basic KV REST html UI #224

merged 11 commits into from
Dec 18, 2014

Conversation

andybons
Copy link
Contributor

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.

Andrew Bonventre added 3 commits December 15, 2014 19:23
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.
@tbg
Copy link
Member

tbg commented Dec 16, 2014

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.

@andybons
Copy link
Contributor Author

@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?

@andybons
Copy link
Contributor Author

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
@tbg
Copy link
Member

tbg commented Dec 17, 2014

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.

@andybons
Copy link
Contributor Author

Thanks, Tobias!

@tbg
Copy link
Member

tbg commented Dec 17, 2014

You're welcome.
Btw, can we use embedfile to embed the ssl certs for testing? It's a minor annoyance that now their path is hard coded in the test relative to the build directory, when ideally they shouldn't have external refs. This creates awkwardness around having to run the tests from the package they belong to.

@spencerkimball
Copy link
Member

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.

@andybons
Copy link
Contributor Author

Sounds good.

Do we want to use embedfile for certs like @tschottdorf wants?

@tbg
Copy link
Member

tbg commented Dec 17, 2014

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).

@tbg
Copy link
Member

tbg commented Dec 17, 2014

@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.

@tbg
Copy link
Member

tbg commented Dec 17, 2014

@andybons
Copy link
Contributor Author

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.

@spencerkimball
Copy link
Member

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.

@andybons
Copy link
Contributor Author

PTAL. Full Angular goodness.

@andybons andybons changed the title Add basic KV REST html UI and embedfile tool Add basic KV REST html UI Dec 18, 2014
</head>
<body>
<header class="appNav">
<a href="#/" class="appNav-link appNav-homeName">Cockroach</a>
Copy link
Member

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.

Copy link
Contributor Author

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.

@spencerkimball
Copy link
Member

LGTM and am really happy to get a start on an admin UI.

I agree with Tobias that we should integrate with Swagger.

@andybons andybons mentioned this pull request Dec 18, 2014
andybons added a commit that referenced this pull request Dec 18, 2014
@andybons andybons merged commit 308a0ef into master Dec 18, 2014
@andybons andybons deleted the andybons/restui branch December 18, 2014 03:06
@andybons
Copy link
Contributor Author

@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.

@spencerkimball
Copy link
Member

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
/ui
/web
/www

@andybons
Copy link
Contributor Author

I like ui. Short and sweet.

@spencerkimball
Copy link
Member

Cool, let's do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants