Skip to content

Commit

Permalink
Merge pull request #1 from aerawatcorp/develop
Browse files Browse the repository at this point in the history
Develop (Please sync from the main stream)
  • Loading branch information
Ashinsk authored May 31, 2024
2 parents 3116d34 + 9441ce2 commit 5053a3b
Show file tree
Hide file tree
Showing 3 changed files with 47 additions and 0 deletions.
15 changes: 15 additions & 0 deletions .project/docs/CANESERVER.md
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.


8 changes: 8 additions & 0 deletions .project/docs/JAGGERY.md
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.**
24 changes: 24 additions & 0 deletions .project/docs/README.md
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.


0 comments on commit 5053a3b

Please sign in to comment.