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

[Viliam Rockai]

On Po, 2015-08-17 at 04:31 -0400, Lucas Ponce wrote:
> > 
> > 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 ?
> 

Yes

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

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.

> WDYT ?
> 




> Lucas
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev