-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from aerawatcorp/develop
Develop (Please sync from the main stream)
- Loading branch information
Showing
3 changed files
with
47 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
#CANESERVER | ||
|
||
- A flask application intended to be a high available edge node to serve the content cache. | ||
- Get content from the JAGGERY server and serve accordingly. | ||
|
||
|
||
# Endpoints | ||
- /master/ (Serves the master schema) | ||
- /r/:idx/:version/:slug (the versioned url thats time lived as per the catalog definition rules) | ||
|
||
## HTTP APIs for cache management | ||
- DELETE to invalidate some particular version of a cache | ||
- PATCH to trigger the JAGGERY to fetch the latest content. | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
## JAGGERY | ||
A content and cache definition manager in the Sugarcane project. | ||
|
||
- Written in Django | ||
- Catalog Model (the master schema manager) | ||
- Store Model (The cache for each API Node) (This can be replaced to other caching storages) | ||
|
||
**Workers and other provision should run in the backend as per the rules to update the content stored in the Jaggery Cache Stores.** |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,25 @@ | ||
# Implementation | ||
|
||
How should a sugarcane powered client application should make caching decisions ? | ||
|
||
## Fetching the master | ||
- Respect the master schema expiry time as the main authority | ||
|
||
## Fetching the nodes | ||
|
||
### When child node expires ? | ||
- if master is not expired ? - do as said in the last fetched master | ||
- if the master is also expired ? - fetch the master first and proceed as said in the new master | ||
|
||
### When child node is not expired ? | ||
check the master expiry | ||
- if the master is not expired ? - check if child node version is already updated in the fetched master (The cached child content might be obsolete already) | ||
- if the master is expired ? - fetch the master and proceed as said in the master | ||
|
||
### When live=True in the child node ? | ||
- skip the cache and fetch from production endpoint | ||
|
||
### When live=True in the master node ? | ||
- fetch from live regardless of any settings. But still respect the expiry settings in the master schema. Means, fetch master next time to see if the `live` flag has been updated to be false or removed. | ||
|
||
|