[jira] [Comment Edited] (STORM-1339) Evaluate/Port JStorm UI Elements

["Jark Wu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/STORM-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029845#comment-15029845 ] 

Jark Wu edited comment on STORM-1339 at 11/27/15 12:50 PM:
-----------------------------------------------------------

As JStorm has a redesigned Web-UI with clear and clean code. It's totally different from Storm's UI including REST API, so I post here to have an evaluation first before migration. I have listed the core differences between them below.


**Multi-Cluster**
- JStorm: YES
- Storm: None
- Note:  With the increasing scale of the cluster, the number of clusters is gradually increasing. If we continue to use one cluster on web ui, it is too difficult for maintenance. In addition, for some online applications, it's painful to apply for machines, open ports, public ip/domains, and so on. With multi-cluster mode, it's easy to handle hundreds clusters in one web ui.

**UI Design**
- In my opinion, the JStorm UI is much more pretty and has a better user experience, especially topology graph, 30-minutes metric trend graph and log viewer. And JStorm UI provides abundant metrics which is very helpful for debugging and tuning. However, Storm UI is a bit difficult to use. Please refer to
http://storm.taobao.org to have a look JStorm UI. Any feedbacks about UI are welcome.


**UI Deployment**
- JStorm: Do not depend on jstorm environment, just put the ui war into tomcat(or other container), it works !
- Storm: Need to install storm on the machine first.
- Note: we can evaluate it

**Web Framework**
- JStorm: Spring MVC
- Storm: HTML + REST
- Note: SpringMVC is widely used and the development is very convenient. HTML + REST is also ok, but the template code is a little unreadabl now, too much separate templates so that it's hard to find which position is it in the page. If we choose HTML+REST way, maybe we can replace Mustache with [Vue.js](http://vuejs.org/) which is a MVVM component for building web interfaces with two-way data-binding feature like Angular but much lighter and faster. 
	- Using Vue.js, we can easily implement separating front-end and back-end.
	- Using Vue.js, there is no need to split template and HTML, we can finish all things in one file with much cleaner and clearer code. It’s in fact much simpler if things are just in the same file. The context switching of jumping back and forth between two files actually makes the development experience much worse. 
	- Vue.js has been used in JStorm UI.

**REST API**
- JStorm: using Spring boot
- Storm: plan to use Jersey
- Note:  We can choose one based on strengths and weaknesses.
	- Advantage of Jersey:
		1. Jersey implement jax-rs standand. Spring build their own set of Api, did not follow the jax-rs specification. In other words, the REST service developed by Jersey can be transferred to other jax-rs (e.g. RESTEasy) easily. However Spring can not. 
		1. Jersey framework is more light, the performance of REST application implemented in Jersey is about 2x than Spring's.
	- Advantage of Spring:
		1. Spring boot has been widely used in micro-service and many companies nowadays. 
		2. Spring can help us develop quickly and conveniently as it has technology like Ioc, AOP.
		3. Spring's ecosphere is good, it provides rich libraries , such as Spring Security which is helpful to build UI/REST access control.
		1. Spring is very popular, Spring's community is very active. Spring has full documents, much more examples.
		2. With better modularization, maintenance costs will be less.


**Logview**
- JStorm: return plain log, jstack, directory list
- Storm: return HTML which contains logs and buttons.
- Note: Storm users need to send an HTTP request to supervisor. In the situation that the network between user and supervisor is disconnected, user can not get the log. This situation is very common. However JStorm's web server will send the request for user to supervisor and return HTML to user, so that user do not need to communicate with supervisor.


So I suggest to migrate JStorm UI as the Storm 2.0 UI. Although this issue is in phase 2, I think it's fine to evaluate whether to deprecate Storm UI and start it as soon as REST issue is done. In addition, as far as I am concerned, we should replace logview with JStorm's way or static HTML+REST.

BTW, I wrote all jstorm ui code alone, and I have reviewed storm code many times. I'm familar with both. So I hope I can do some contributions for this issue.
	
Any comments are welcome.




was (Author: jark):

As JStorm has a redesigned Web-UI with clear and clean code. It's totally different from Storm's UI including REST API, so I post here to have an evaluation first before migration. I have listed the core differences between them below.


## Multi-Cluster
- JStorm: YES
- Storm: None
- Note:  With the increasing scale of the cluster, the number of clusters is gradually increasing. If we continue to use one cluster on web ui, it is too difficult for maintenance. In addition, for some online applications, it's painful to apply for machines, open ports, public ip/domains, and so on. With multi-cluster mode, it's easy to handle hundreds clusters in one web ui.

## UI Design
- In my opinion, the JStorm UI is much more pretty and has a better user experience, especially topology graph, 30-minutes metric trend graph and log viewer. And JStorm UI provides abundant metrics which is very helpful for debugging and tuning. However, Storm UI is a bit difficult to use. Please refer to
http://storm.taobao.org to have a look JStorm UI. Any feedbacks about UI are welcome.


## UI Deployment
- JStorm: Do not depend on jstorm environment, just put the ui war into tomcat(or other container), it works !
- Storm: Need to install storm on the machine first.
- Note: we can evaluate it

## Web Framework 
- JStorm: Spring MVC
- Storm: HTML + REST
- Note: SpringMVC is widely used and the development is very convenient. HTML + REST is also ok, but the template code is a little unreadabl now, too much separate templates so that it's hard to find which position is it in the page. If we choose HTML+REST way, maybe we can replace Mustache with [Vue.js](http://vuejs.org/) which is a MVVM component for building web interfaces with two-way data-binding feature like Angular but much lighter and faster. 
	- Using Vue.js, we can easily implement separating front-end and back-end.
	- Using Vue.js, there is no need to split template and HTML, we can finish all things in one file with much cleaner and clearer code. It’s in fact much simpler if things are just in the same file. The context switching of jumping back and forth between two files actually makes the development experience much worse. 
	- Vue.js has been used in JStorm UI.

## REST API
- JStorm: using Spring boot
- Storm: plan to use Jersey
- Note:  We can choose one based on strengths and weaknesses.
	- Advantage of Jersey:
		1. Jersey implement jax-rs standand. Spring build their own set of Api, did not follow the jax-rs specification. In other words, the REST service developed by Jersey can be transferred to other jax-rs (e.g. RESTEasy) easily. However Spring can not. 
		1. Jersey framework is more light, the performance of REST application implemented in Jersey is about 2x than Spring's.
	- Advantage of Spring:
		1. Spring boot has been widely used in micro-service and many companies nowadays. 
		2. Spring can help us develop quickly and conveniently as it has technology like Ioc, AOP.
		3. Spring's ecosphere is good, it provides rich libraries , such as Spring Security which is helpful to build UI/REST access control.
		1. Spring is very popular, Spring's community is very active. Spring has full documents, much more examples.
		2. With better modularization, maintenance costs will be less.


## Logview
- JStorm: return plain log, jstack, directory list
- Storm: return HTML which contains logs and buttons.
- Note: Storm users need to send an HTTP request to supervisor. In the situation that the network between user and supervisor is disconnected, user can not get the log. This situation is very common. However JStorm's web server will send the request for user to supervisor and return HTML to user, so that user do not need to communicate with supervisor.


So I suggest to migrate JStorm UI as the Storm 2.0 UI. Although this issue is in phase 2, I think it's fine to evaluate whether to deprecate Storm UI and start it as soon as REST issue is done. In addition, as far as I am concerned, we should replace logview with JStorm's way or static HTML+REST.

BTW, I wrote all jstorm ui code alone, and I have reviewed storm code many times. I'm familar with both. So I hope I can do some contributions for this issue.
	
Any comments are welcome.



> Evaluate/Port JStorm UI Elements
> --------------------------------
>
>                 Key: STORM-1339
>                 URL: https://issues.apache.org/jira/browse/STORM-1339
>             Project: Apache Storm
>          Issue Type: New Feature
>          Components: storm-core
>            Reporter: Robert Joseph Evans
>            Assignee: Jark Wu
>              Labels: jstorm-merger
>
> The JStorm UI has some nice features, especially graphing in the newest version (Not in our repo)
> I would be nice to evaluate not just their features, but get a real UI designer to evaluate the user experience and make something that is useful and intuitive for our users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)