Remote Settings: align endpoints and querystrings with desktop client
leplatrem opened this issue · 2 comments
I read the code of the Remote Settings client, and could see that it uses different endpoints and querystrings than our desktop client (or our rust client).
I would like to raise your attention on this for several reasons 😊
First, the remote settings endpoints do not require etag parsing etc., so it could simplify your code.
And second, the fact this client uses different endpoints (eg /records instead of /changeset) and querystrings (eg. gt_last_modified instead of _since) has a significant impact on the traffic on our origin servers.
For example, desktop hasn't used the /records endpoints for 4 years, and were finally happy to see the end of the long tail of legacy clients...
I see that your client supports server side queries like min,max, and lot more. For the same reasons related to CDN cache cardinality, our model for Remote Settings is not to let clients do server-side filtering (although it's technically possible via the Kinto API), but to download the records locally, and filter them locally.
In the same way, the /records CDN cache TTL should not be considered deterministic, whereas the /changeset endpoint takes a _expected= parameter for cache busting.
As a side note, we discovered a very serious security flaw on attachments recently. We could guarantee the integrity of our data (server and client) because we had signature verification. Not implementing them breaks one of the promise we make for our service on data integrity.
We can take responsibility for the divergence of your client and ours, because we never documented how to write one for remote-settings, which is a layer on top of Kinto (with changesets, signatures etc.).
We never did because we didn't want client fragmentation (partly for the above reasons). Unfortunately, it seems already too late to hope for that, hence it's now a TODO.
As owners of the server parts, which are accountable to deliver data to million of clients efficiently and cheaply, we would be very grateful if you could include us (remote-settings-reviewers) when you make changes to your client code. It would help us understand our clients diversity and possibly get prepared for changes in the shape of traffic on our servers in case you really need to diverge from desktop.
Ideally, since the decision to roll out an ad-hoc client was originally motivated by limited timeline and resources, I still think that it would make sense to unify the Rust clients and have a unique and solid implementation of reference. I would be happy to help plan such a mid-long term project and offer as much help as needed 🙏
┆Issue is synchronized with this Jira Task
┆Epic: Important backlog
Thanks for the note. I believe you were well aware of this component from before it was created, right? I'm not sure how to move forward on your suggestions though given it's used quite extensively, even directly by Fenix. Regardless, I'm not on a team which uses it in any capacity, so I'll leave any further comments for those who are.
Note we are now tracking issues in bugzilla - I've just created a template in #6196 to try and steer people in the right direction in the future. If you like, you can move this to the "Remote Settings" component there and can then watch the component. We hope to move to moz-central in the next month or few, and when that happens you will be able to watch the patch in phabricator too 🎉