Description:
Currently, when consuming LifeUp Cloud endpoints (such as /tasks, /items, /skills), there is no cache validation mechanism available (like ETag or Last-Modified headers).
To check if the local data (cache on the notebook/PC) is outdated, we are forced to download the full JSON from each endpoint again. Although the data is lightweight, on slower networks or for those who query frequently (e.g., every 1 minute for dashboards), this generates unnecessary traffic and needlessly drains the phone's battery.
Suggestion 1 (My preferred - Aggregated Hash Endpoint):
Create a lightweight endpoint, for example, GET /meta/checksum, which returns a unique hash (MD5 or SHA-1) combined from all the main endpoints (tasks, items, skills, history, feelings).
Example response:
json
{
"global_hash": "a1b2c3d4e5f6...",
"resources": {
"tasks": "hash_tasks_123",
"items": "hash_items_456",
"skills": "hash_skills_789"
},
"timestamp": 1720300000
}
Usage flow: The script on the PC makes a request to this tiny endpoint (just a few bytes). It compares it with the hash saved locally. If it has changed, then it downloads the full endpoints to update the cache. This drastically reduces network traffic.
Suggestion 2 (Easier to implement - Database Timestamp): Instead of calculating the JSON hash (which requires serializing all the data), the server could simply query the MAX(modified) (last modification date) from the LifeUp SQLite database tables and return it in a Last-Modified header or within a last_updated field.
Example response for Suggestion 2:
json
{
"last_updated_tasks": 1720300000,
"last_updated_items": 1720250000,
"last_updated_skills": 1719900000
}
Note: This approach is computationally much cheaper for the phone, as it doesn't require reading and transforming all the data into JSON to generate the hash, only a simple SQL query to the database.
Justification for the developer:
Implementation is straightforward (especially Suggestion 2, which uses the modified field that already exists in the tables).
Does not break compatibility with previous versions.
Improves the developer experience for those doing continuous integrations (automations, dashboards, syncing with Notion/Google Sheets).
Thank you in advance for your consideration!
Description:
Currently, when consuming LifeUp Cloud endpoints (such as /tasks, /items, /skills), there is no cache validation mechanism available (like ETag or Last-Modified headers).
To check if the local data (cache on the notebook/PC) is outdated, we are forced to download the full JSON from each endpoint again. Although the data is lightweight, on slower networks or for those who query frequently (e.g., every 1 minute for dashboards), this generates unnecessary traffic and needlessly drains the phone's battery.
Suggestion 1 (My preferred - Aggregated Hash Endpoint):
Create a lightweight endpoint, for example, GET /meta/checksum, which returns a unique hash (MD5 or SHA-1) combined from all the main endpoints (tasks, items, skills, history, feelings).
Example response:
json
{
"global_hash": "a1b2c3d4e5f6...",
"resources": {
"tasks": "hash_tasks_123",
"items": "hash_items_456",
"skills": "hash_skills_789"
},
"timestamp": 1720300000
}
Usage flow: The script on the PC makes a request to this tiny endpoint (just a few bytes). It compares it with the hash saved locally. If it has changed, then it downloads the full endpoints to update the cache. This drastically reduces network traffic.
Suggestion 2 (Easier to implement - Database Timestamp): Instead of calculating the JSON hash (which requires serializing all the data), the server could simply query the MAX(modified) (last modification date) from the LifeUp SQLite database tables and return it in a Last-Modified header or within a last_updated field.
Example response for Suggestion 2:
json
{
"last_updated_tasks": 1720300000,
"last_updated_items": 1720250000,
"last_updated_skills": 1719900000
}
Note: This approach is computationally much cheaper for the phone, as it doesn't require reading and transforming all the data into JSON to generate the hash, only a simple SQL query to the database.
Justification for the developer:
Implementation is straightforward (especially Suggestion 2, which uses the modified field that already exists in the tables).
Does not break compatibility with previous versions.
Improves the developer experience for those doing continuous integrations (automations, dashboards, syncing with Notion/Google Sheets).
Thank you in advance for your consideration!