Sensu-go: Move object filtering for web-ui out of backend to frontend

[grepory]

We currently filter objects for the webui in the backend. The webui passes the filter expression and the backend evaluates it in the graphql resolvers--or something along those lines.

Instead, we should reevaluate what the filter expression syntax is (@jamesdphillips suggested, and i agree with, something lucene-like), and we should evaluate the filter expression in the front-end.

[jamesdphillips]

imo - I think it will be better to implement sorting, pagination and filtering all on the backend. Otherwise, we would be in a position where, if we wanted both sort and filter a set of data, we would have to synchronize the entire set of data (worse case events) to the frontend and then apply the filter(s) and sort. While fine for smaller installations, it would likely become untenable for large installations with thousands of events, checks, entities, etc.

(Worst case on mobile where latency and jitter are higher and clock speeds are 2-4X slower.)

[jamesdphillips]

A potentially cool thing about using a lucene-like syntax for filter is that we could use the OpenAPI/GraphQL schema(s) to validate the query.

[grepory]

That's fair.

The specific problem we have to solve with filtering is that otto VMs are cached/reused. So, you have 8 otto VMs per backend, and if I, for example, extend Array.prototype via the webui's filter box, then whatever VM I hit on whatever backend I hit, has that extension but none others do.

So at the very least, we need to not use javascript for filtering via the webui.

@echlebek makes a pretty good point, that you can filter events using javascript in the webui with the runtime environment in the backend which is really nice for quickly iterating on a filter you're working on.

I think that if we can change the filter syntax in the webui / or any other point of interaction with the backend to be something like lucene, we should evaluate if there's a way we can provide that fast iteration filter development funcationality in the webui that people get with javascript display input filtering they have now.

Regarding graphql assisting with lucene stuff, does it make sense to potentially move to using graphql in sensuctl or can we just provide a reusable lucene filter interface that both the REST API and GraphQL API can use?

[echlebek]

I think from a perspective of trade offs, it's better to filter in the frontend. Contending with arbitrary javascript from readonly users could be quite problematic from a security perspective.

Really, even with thousands of items, filtering in the frontend should still be reasonable. V8 is much faster than otto.

[grepory]

@echlebek the bandwidth / transfer constraints are kind of the killer here. If we're targeting mobile as a platform we want to healthily support (we are), then it's a non-starter to filter in the frontend, imo.

[echlebek]

Maybe govaluate still has a place in our project. :)

[jamesdphillips]

fwiw, I have _heard_ existing customers already have performance issues with Uchiwa in large installations. /cc @palourde

[grepory]

@jamesdphillips there are a couple of concerns with larger installations right now.

Cluster aggregation in the uchiwa server goes and fetches data to all backends, aggregates them, and then returns the results to the dashboard. That's pretty expensive.

Then yeah... Uchiwa does what @echlebek is suggesting which is it keeps a local cache of data from every cluster and does filtering/pagination/etc. locally in the browser. And yeah... It seems to be pretty rough.

[palourde]

For reference, I have two layers of filtering in Uchiwa; the backend would filter resources based on the provided dc query parameter and then the frontend would filter, using RegExp, on whatever expression users provided.

The main performance issue I face with Uchiwa is currently with the JS stuff, when you list all resources. If you have 9000 clients, all 9000 will be loaded by the frontend. An easy solution would be to perform pagination but then the challenge you have is that filtering needs to be done by the backend in order to only return the x first resources that match your filter, for example.

[echlebek]

@palourde so are you saying that the reason the uchiwa filtering is slow because it can involve thousands of HTTP requests?

I think client-side filtering is very possible and we should at least try it for the dashboard. :)

[palourde]

@echlebek No sorry, the problem was that all 9000 clients were loaded in your browser, and then filtering was performed on those clients; this had to be done every x seconds so it quickly became expensive.

To be fair, this was all done in Angular 1 by someone with 0 Javascript experience (me) so it was definitely suboptimal.

[jamesdphillips]

Despite my objections above, in the context of OSS, I do think this is something we should tackle. If large installations are using OSS I do think it is far more preferable that perf impact is isolated to front-end.

We could investigate using web-workers or other approaches to mitigate UX impact.

https://docs.google.com/document/d/1hK56BptiFk67UJ2zpyubj99cldaxXBLvd33_1udxBHQ

[jamesdphillips]

PR #2951 made improvements around query performance, and after having some time pass without issue, I think it is fair to close this issue.