1266885 - Replace server-side filtering with client-side filter expressions

Status: RESOLVED FIXED

(Shield :: General, defect)

Description

[Osmose [:osmose, :mkelly]]

We've decided to replace the existing server-side filtering scheme with fully-client-side filtering using "filter expressions".

Instead of having a bunch of form inputs for various forms of filtering, admins will be able to write a filter expression in JEXL[1]. The system addon will download all enabled recipes, and evaluate the filter expressions on the client to determine which ones will be executed. Filter expressions will be given a context that will include the telemetry ping, the time according to the Normandy server, the user's geolocated country code, etc.

The self-repair endpoint will also support filter expressions, but will have a reduced amount of data available for filtering (e.g. the telemetry packet will not be present). Missing data in a JEXL expression gets evaluated as undefined, which should work fine to cover the situations we'll hit before the system addon hits release and we can disable the self-repair endpoint completely.

Due to the ongoing work on the new admin interface, this change will involve removing the classifier preview for previewing what recipes will be sent to a given client, as they logic is changing and updating the existing preview doesn't make sense since it's going to be ported soon anyway.

[1] https://github.com/TechnologyAdvice/Jexl

Comment 1

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

(Mind sharing a bit about reasoning here, big picture wise?)

Comment 2

[Osmose [:osmose, :mkelly]]

Sure. 

Matt_G has been requesting a feature like this from us for a while. There's some major benefits:

- Writing and reading filter expressions is easier to reason about (, because the logic of the comparison is in front. With the old form setup, you had to mentally AND all the fields together, _except_ for empty fields. Here you can see something like "(normandy.locale == 'en-US' && normandy.country == 'uk')" and quickly see what it's filtering on.

- Adding things to filter on is as simple as making them available in expressions. For example, we can add the telemetry ping data to the filter context easily, making all of telemetry filterable.

- The system of operators allow for many types of comparisons that are hard to express in normal forms, like comparing version number ranges. This also helps keeps the system flexible to new types of filtering when there's not active work being done on the site.

- We came up with the idea of using filter expressions for encoding feature recommendation filters as well; coming up with a UI for specifying "5 clicks within any 5 minute period" was really hard.

The main downside is that, because some data we want to filter on will not be available to the server, we'd either have to write two parsers (one for the server and one for the client), or do all our filtering on the client and write one parser. We opted for the latter; we already were going to have to do client-side filtering anyway, and it won't affect future features like counting executions since we can't count those until after they've been executed.

We spent a few hours prototyping to see if it'd work out, and found JEXL, which conveniently fit pretty much all our needs and saved us a lot of work. mythmon and I got to a point where we're pretty confident it'll work out, leading to this bug to make it official.

There's also a few ideas around validation we have:

- Validate that the filter expression is valid
- Validate that only known variables are used
- Validate the types of values that are supposed to be countries/locales/release channels, or validate comparisons on variables that are known to be these types. We can use similar techniques to get the country values for listing in the admin.
- We could write offline or standalone tests for complex filter expressions if we want.

We'll be launching with the old filter interface, but we'll have support for filter expressions in the self-repair endpoint soon after launch.

Comment 3

[[github robot]]

Commits pushed to master at https://github.com/mozilla/normandy

https://github.com/mozilla/normandy/commit/01ca8558645737571380fc84217a433a6e646977
[bug 1266885] Replace recipe filters with filter expressions.

https://github.com/mozilla/normandy/commit/e04c7441b10e2acc99a10452480ae3556c3b8b08
Merge pull request #114 from Osmose/client-filtering

[bug 1266885] Replace recipe filters with filter expressions.

Comment 4

[Michael Cooper [:mythmon]]

The current version of the service, the shim code, and the addon all use client side filtering. I think we're done here.