[Hawkular-dev] Extra back-end for our front-end

Lucas Ponce lponce at redhat.com
Mon Aug 17 04:31:30 EDT 2015


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






More information about the hawkular-dev mailing list