Content
View differences
Updated by Oleksii Borysenko about 1 month ago
**Prerequisites:**
We have a task to make Projects and WorkPackages be accessible in offline. To achieve this, we have to implement local in-app caching. The most logical way to implement it is to use 'update\_at' filter and fetch only a delta between server data and local data.
**Why this approach doesn't work:**
it actually works, but in some cases we may lose synchronisation:
\- if a user was kicked out from the project
\- if a user has a shared WorkPackage from the project that he/she doesn't belong to
**Possible way of solving the above cases that we tried:**
\- fetching a list of all project’s ids from the server and compare them with the local list of ids.
\- use another filter to fetch the delta. for example, 'latest\_activity\_at'
**Why the first approach doesn't work:**
it works, and we use it now for caching projects. But for WorkPackages this approach will not work because it could be thousands of ids that need to be synced in the case of WorkPackages list.
**Why the second approach doesn't work:**
it will work, but in this case all changes in the project (i.e. creating/deleting WorkPackage) will affect changes in the cache as well. so every time during the sync, we will fetch all data again.
**What else can we use:**
1\. we don't know. but it could be that **we miss some important approach** or solution here (i.e. some filters that can help).
2\. maybe we can use **some changes in the API** that help us here:
- maybe adding an additional filter for the WorkPackages list will solve the problem
- maybe getting an API for a journal can help so we can get data from there.
- maybe we can send all our ids in one request or vice versa: receive all ids from the server in one response (without pagination).
<br>
<br>
<br>
<br>
We have a task to make Projects and WorkPackages be accessible in offline. To achieve this, we have to implement local in-app caching. The most logical way to implement it is to use 'update\_at' filter and fetch only a delta between server data and local data.
**Why this approach doesn't work:**
it actually works, but in some cases we may lose synchronisation:
\- if a user was kicked out from the project
\- if a user has a shared WorkPackage from the project that he/she doesn't belong to
**Possible way of solving the above cases that we tried:**
\- fetching a list of all project’s ids from the server and compare them with the local list of ids.
\- use another filter to fetch the delta. for example, 'latest\_activity\_at'
**Why the first approach doesn't work:**
it works, and we use it now for caching projects. But for WorkPackages this approach will not work because it could be thousands of ids that need to be synced in the case of WorkPackages list.
**Why the second approach doesn't work:**
it will work, but in this case all changes in the project (i.e. creating/deleting WorkPackage) will affect changes in the cache as well. so every time during the sync, we will fetch all data again.
**What else can we use:**
1\. we don't know. but it could be that **we miss some important approach** or solution here (i.e. some filters that can help).
2\. maybe we can use **some changes in the API** that help us here:
- maybe adding an additional filter for the WorkPackages list will solve the problem
- maybe getting an API for a journal can help so we can get data from there.
- maybe we can send all our ids in one request or vice versa: receive all ids from the server in one response (without pagination).
<br>
<br>
<br>
<br>