Hey all, As we put more and more functionality into Hawkular, the more and more logic is put into the front-end itself, too. From my perspective, we're dealing with too much stuff that doesn't even belong to the front-end anyway. I believe we should create a new back-end module, which would connect all the existing modules with the front-end. This module may even be maintained by the front-end team, since it'll evolve and mutate very fast - to suit the UI needs. There are several use-cases which call

for such module. For example to create all the alert entities needed for alerting you need to create a: * Trigger (per alerting "entity") * Dampening (one or more)

* Condition (one or more) Each of those has its separate endpoint and creation of each may fail. So basically we should (we don't do that yet, we just assume everything went all right) even deal with transactions in the front-end right now. >From the UI perspective, this is just a single entity "Alert definition". Another question is - when should those objects be created? Once you add an URL - that's pretty easy (for URLS). But, in my opinion, for JVMs they should be created once the resource is discovered, not the 1st time the resource is accessed by UI. And the situation will be more complicated with new resources. Being able to get some predefined sets of metrics would be another nice feature. I.e., right now, we do 3 requests (User, maximum, committed) to get the data for the "JVM Heap Usage" graph (and other graphs, too). Being able to process those data on a server and send it the the front-end in one bulk would be pretty neat. I believe adding a new module to the back-end, which role would be to connect the UI to the rest of Hawkular services would be beneficial for performance, testability and robustness of the whole app. WDYT?

Viliam _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> > On 8/12/2015 9:27 AM, Viliam Rockai wrote: > > Hey all, > > > > As we put more and more functionality into Hawkular, the more and more > > logic is put into the front-end itself, too. From my perspective, we're > > dealing with too much stuff that doesn't even belong to the front-end > > anyway. I believe we should create a new back-end module, which would > > connect all the existing modules with the front-end. This module may > > even be maintained by the front-end team, since it'll evolve and mutate > > very fast - to suit the UI needs. There are several use-cases which call > > This makes sense to me and is probably overdue. What you're talking > about here is basically the Hawkular application-level server-side > code. The code that is too high-level or specific to be at the > component level. or umbrellas work that spans multiple components. This > code should be providing the business logic that supports the UI or > other aspects of Hawkular. > > > > for such module. For example to create all the alert entities needed for > > alerting you need to create a: > > * Trigger (per alerting "entity") > > * Dampening (one or more) > > nit: actually, For Dampening, this is (zero or 1) for a Trigger. > > > * Condition (one or more) > > > > Each of those has its separate endpoint and creation of each may fail. > > So basically we should (we don't do that yet, we just assume everything > > went all right) even deal with transactions in the front-end right now. > > >From the UI perspective, this is just a single entity "Alert > > definition". Another question is - when should those objects be created? > > Once you add an URL - that's pretty easy (for URLS). But, in my opinion, > > for JVMs they should be created once the resource is discovered, not the > > 1st time the resource is accessed by UI. And the situation will be more > > complicated with new resources. Being able to get some predefined sets > > of metrics would be another nice feature. I.e., right now, we do 3 > > requests (User, maximum, committed) to get the data for the "JVM Heap > > Usage" graph (and other graphs, too). Being able to process those data > > on a server and send it the the front-end in one bulk would be pretty > > neat. > > > > I believe adding a new module to the back-end, which role would be to > > connect the UI to the rest of Hawkular services would be beneficial for > > performance, testability and robustness of the whole app. > > > > WDYT? > > So, perhaps a new WAR under hawkular/server or something like that? > > > > > Viliam So, if I understood the scenario, from UI perspective it's like you would need a backend module that can talk directly with the Java API of the component to prepare a customized/optimized REST API that suits hawkular UI needs, right ?

In Alerts, the API is very CRUD oriented as it's a first version, but with UI feedback perhaps we can adapt it and extend it with other operations (bulk definitions creation or similar).

WDYT ?

Lucas _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "Heiko W.Rupp" <hrupp(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Monday, August 17, 2015 6:18:55 AM Subject: Re: [Hawkular-dev] Extra back-end for our front-end On 17 Aug 2015, at 12:35, Viliam Rockai wrote: > It's not only about APIs of separate modules, it's about bringing those > APIs together in one place other than the frontend. This way you still > get the feedback from the UI team, but the app itself would be more > stable, since we'd get rid of multi-step operations being handled by the > UI. And on top other clients can (re-)use that functionality instead of implementing it over and over again. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On 08/17/2015 07:53 PM, Stefan Negrea wrote: > 1) The curent microservices are not very granular and the number is small; there are only 3 major microservices to interact with and the functionality for each is broad. > 2) Each microservice can quickly add supporting methods for the UI. This will polish the API of each microservices because it has to be easily consumable. > 3) We are forced to stay into microservice mode (it's a mindset!) and we will continue to develop decoupled services. > 4) Increased potential of each service to be consumed independently of the whole because: > a) the API will be more polished > b) each service is always used in the mode that will be integrated outside > 5) There is no additional place to address service quirks; each service has to solve interface quirks right away to be consumable. I see the API Gateway component as the fastest and first place to accumulate technical debt. +1 , specially for points 1 and 5.

On Sep 3, 2015, at 8:52 AM, Jay Shaughnessy <jshaughn(a)redhat.com&gt; wrote: Nice. Truth be told, I miss GWT. For that short period I could actually be a UI dev. I miss nested async responses.