Future need for RHQ/JON to run in console environments such as Uberfire and/or Hawt.io
Current architecture:
Monolithic architecture: one large app not easily split up. For example, peeling off one screen to put in a console elsewhere
Current architecture doesn't allow for unit testing (MVP solution for SmartGWT not very practical like it is for GWT because SmartGWT uses a completely different widget library hierarchy)
SmartGWT lock in; interop with other libraries/widgets etc
Complicated infrastructure: GWT Dev mode going away; uncertainty about super dev mode working well with SmartGWT
Size of our SmartGWT app is huge; Also, the overall background CPU use of our app is quite high
Technology Time Lag: technology must first make it into GWT(6-1 year behind javascript, if at all) and then into SmartGWT(1+ yr after GWT)
The SmartGWT Mobile strategy is via another product SmartGWT.mobile and would result in a significant rewrite of existing system; not to mention total redesign to take advantage of mobile ergonomics
Integrating with slick new widgets from other javascript libraries difficult (and not advised from Isomorphic)
The browsers are changing too fast (6 week cycles) for libraries like GWT/SmartGWT to keep up. This trend only accelerates with mobile.
Decouple the front-end from back-end; Allow front-end and backend technologies to move at their own pace and be replaced independently
Provide Mobile (responsive design for all screen sizes)
Increase performance (both size and speed)
Utilize the new JBoss Common look and feel: Patternfly for Community Projects and RCUE for Red Hat Products
Open the opportunity to use new Usability Friendly widgets (various interesting javascript widgets for a better user experience)
Provide a dynamic plugin mechanism to customize/extend the UI at runtime
Lower the barrier to entry write screens --> more community involvement
Backend Interface: HTTP REST json documents (don't care about what is running the REST interface)
Technology changes are always a controversial decision as the choices must be made to last for several years. The independence of the back-end from the UI will allow for better future decisions as well, that will have a much narrower impact on the total number of the pieces affected (resulting in smaller costs of change).
As part of the console consolidation project (to end JBoss product console proliferation) we must also have the ability to run within a future console framework like:
Essentially console integration is a JBoss standard replacement for the RHQ Dashboard functionality – a universal dashboard that multiple JBoss products/Community Projects can plug into.
More than just a universal dashboard though, it is a dynamic plugin container that discovers plugins at runtime and enables functionality based on presence of services.
It's looking like there will be two development tracks:
1. Hybrid, RHQ 4.11+ New screen development to existing codebase using Angular piecemeal. This way, we get some experience with Angular soon and everything that we create will be easily migrated to the new stack with minimal effort.
2. New Angular UI, RHQ 5.0: UI rewrite using Angular and integrating to a console framework: Uberfire or Hawt.io. Will also require SSO integration with KeyCloak.