Open Bug 1903124 Opened 1 year ago Updated 1 year ago

Experiment with the official remote settings client + async UniFFI

Categories

(Application Services :: Suggest, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: bdk, Unassigned)

References

Details

(Whiteboard: [disco-])

The iOS team is hoping to use a remote settings client, however they want a caching layer which our remote settings client doesn't provide. This seems like a great time to experiment with bringing in the official remote settings client, which does support that.

The main reason we aren't using the official remote settings client is that it's written in async Rust. We could use the UniFFI async features plus the fairybridge crate to power it. This is slightly experimental and it would be great to test it with some real-world use-cases.

I'm filing this under Suggest since we have a long-term plan to get Suggest to use the official remote settings client.

Whiteboard: [disco-]

I think we want to be careful here - IMO a very bad outcome would be iOS uses the "official" one while Android and Nimbus stick with the existing one. I'd much rather see everything use the same, whether that's moving everyone or just adding caching to our existing one. If the only identified requirement for iOS is that caching, I doubt trying to use that official one with the async complexities just for iOS, while we still ship the old via nimbus is a sensible way forward.

Great point, the outcome I'm aiming for is that all components are on the official client and they are not required to switch to async code. I believe that it's possible to use the official client without switching to async by using pollster to block when calling its async methods, like fairybridge does.

Here's my general plan for this:

  • Create a branch where we bring in official client and expose it via UniFFI
    • Define both a sync and async API for it
    • Probably bring in fairybridge to handle the HTTP calls
  • Let Nish test things out using the branch
  • If the testing is successful, then merge the branch and let iOS start using official client. At this point, we now have 2 remote settings clients in the repo and we should try to move all consumers to the official one.
  • Switch our own components to using the official client, maybe one at a time in case there are issues.
  • Switch Android to using the official client
  • Drop the current client
  • Move components from viaduct to fairybridge and drop viaduct.
Severity: -- → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.