From a39eac712301020718639d29178490cee6a6caaa Mon Sep 17 00:00:00 2001 From: Mathieu Leplatre Date: Tue, 28 Jan 2025 19:04:23 +0100 Subject: [PATCH] ADR for server-side filtering: adjust status and conclusion --- docs/adr/adr_004_server_side_filtering.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/adr/adr_004_server_side_filtering.md b/docs/adr/adr_004_server_side_filtering.md index 4ca0464b..d3f451a8 100644 --- a/docs/adr/adr_004_server_side_filtering.md +++ b/docs/adr/adr_004_server_side_filtering.md @@ -1,6 +1,6 @@ # Server Side Filtering -* Status: proposed +* Status: accepted * Deciders: mleplatre, acottner, najiang * Date: Jan 3, 2024 @@ -31,7 +31,7 @@ In order to choose our solution we considered the following criteria: ## Decision Outcome -Chosen option: if it fits the segmentation requirements, we would pick *Option 2*. We already have all the pieces in place, it is very low tech and low cost, while still providing a good user experiences for editors and publication of data. +Chosen option: in the context of server to server publication, and if the source server can dispatch data in several collections, then *Option 1* is our preferred approach. Otherwise if it fits the segmentation requirements, we would pick *Option 2*. We already have all the pieces in place, it is very low tech and low cost, while still providing a good user experiences for editors and publication of data. ![A diagram showing how data flows from the admin user making a change via Kinto Admin UI. That causing an update in the source collection. Then a data copy cron-job pushes the data to read-only calculated collections. Those are then read by the client.](./adr_004_diagram.jpeg "Proposed Solution Diagram") @@ -54,11 +54,10 @@ The single collections is split into several ones, and the client is able to det If a record is required in different subsets, it is duplicated in each collection. - **Complexity**: N/A -- **User experience**: Bad, even if a script could automate the publication of records into several collections, editors don't have a single source of truth for the content, leading to duplicated actions and data. +- **User experience**: Bad if done by human editors, since they don't have a single source of truth for the content, leading to duplicated actions and data. Good in the context of server-to-server publication where a script can automate the publication of records - **Cost of implementation**: Low. Creating collections is cheap. - **Cost of operation**: Low. Clients download only the subset of data, saving bandwidth. - ### Option 2 - Read-only mirrors With this solution, the main collection is maintained, and several "*side collections*" are created. As with *Option 1*, the clients are able to pick which collection to pull from.