Skip to content

Conversation

@vikhyat
Copy link
Contributor

@vikhyat vikhyat commented Apr 24, 2015

This is the first step towards implementing the web interface refactoring I proposed last year: https://groups.google.com/forum/#!topic/stratosphere-dev/GeXmDXF9DOY

Once this is merged, I can get started with the rest of the refactoring. For now, the actual interface is kept the same, the only change is to how the build is done.

@vikhyat
Copy link
Contributor Author

vikhyat commented Apr 24, 2015

The build is failing because of the license checker (RAT) hanging, not sure why it's happening.

When building locally I get the same issue both on master as well as my topic branch. For testing I had to comment out the RAT section, does anyone know why this is happening?

@StephanEwen
Copy link
Contributor

Wow, this comes with a bit of a surprise, given that it is a followup to a year-old discussion in the pre-Apache project "Stratosphere".
Because such a long time has passed since then, I have started bootstrapping some other work for an improved web frontend.

It consists of two parts:

  1. A REST style backend that produces JSON structures with the information rendered by the frontend (lists of states, timestamps, names, counters, ...).
  2. An angular.js based frontend, that is still much work in progress (someone else is helping me out there)

You can have a look at (1) here "https://github.com/StephanEwen/incubator-flink/commits/web_frontend_2" It supports queries for example like "http://localhost:8082/running//vertices" to get the vertex statuses for all vertices of a job. The nice thing is that it is extremely lightweight, by being a minimal layer on top of netty (which we use for data transport anyways). Before, I was trying to go for jersey/grizzly, but these are heavyweight (25+ dependencies) there were many version conflicts with other dependencies (like YARN).

I hope to be able to share a few screenshots for (2) on the mailing list next week.

How much have you implemented on your side? Can we find a way to bundle the two works together?

@vikhyat
Copy link
Contributor Author

vikhyat commented Apr 24, 2015

Sorry about that, I had given up on my last attempt because I couldn't figure out how to do the Maven-Grunt integration. After working on a few other Maven-based projects since then I figured I'd give it another shot.

I am sure we can bundle the two together, should I start working off the web_frontend_2 branch and send PRs to your fork instead? Is there anything specific you would want me to work on? I couldn't find any discussion on JIRA or the mailing list so I'm not sure how to proceed.

@StephanEwen
Copy link
Contributor

You are definitely welcome to participate in the new web frontend development. Have a look at the branch I sent you and see if you find your way around the new code (it is not too much so far, so it is okay, hopefully).

I am not familiar with Grunt. It says it is a JavaScript automation framework. What is it for, in the context of the web frontend?

@vikhyat
Copy link
Contributor Author

vikhyat commented May 1, 2015

Grunt is basically a front-end build tool. It is useful for things like
concatenating and minifying JavaScript, precompiling templates etc. The
plugin I added also includes bower which can be used to import third party
dependencies like FontAwesome or jQuery instead of bundling them in the
repository.
On Apr 27, 2015 2:03 PM, "Stephan Ewen" notifications@github.com wrote:

You are definitely welcome to participate in the new web frontend
development. Have a look at the branch I sent you and see if you find your
way around the new code (it is not too much so far, so it is okay,
hopefully).

I am not familiar with Grunt. It says it is a JavaScript automation
framework. What is it for, in the context of the web frontend?


Reply to this email directly or view it on GitHub
#623 (comment).

StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 20, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 21, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 21, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 21, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 21, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
StephanEwen added a commit to StephanEwen/flink that referenced this pull request Jul 21, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
@asfgit asfgit closed this in 44ee1c1 Jul 21, 2015
nikste pushed a commit to nikste/flink that referenced this pull request Sep 29, 2015
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
nltran pushed a commit to nltran/flink that referenced this pull request Jan 8, 2016
 - Adds a separate Maven project for easier maintenance. Also allows users to refer to runtime without web libraries.
 - Simple HTTP server based on Netty HTTP (slim dependency, since we use netty anyways)
 - REST URL parsing via Netty Router
 - Abstract stubs for handlers that deal with errors and request/response
 - First set of URL request handlers that produce JSON responses

This closes apache#677
This closes apache#623
This closes apache#297
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants