Merged
Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
When the
X-Starbase-Cacheheader is present, if the query in consideration is aREADoperation (e.g. a SELECT statement) then by default we will cache the results for 60 seconds in our Durable Object storage. You can see thetmp_cachetable will be a generated table in the DO and each row will contain the results of a single query and include the timestamp, ttl expiry, query and the results.From internal testing I have experienced successful optimizations for external data sources cutting down from 1s or greater down to ~50ms. Regardless of the time the non-cached query takes, the cached result usually has a response time of that 50ms ballpark.
Internal data source queries in the Durable Object itself are never cached as those already have incredibly fast read times. However, any external data source connected to the StarbaseDB instance is eligible for becoming cached when the header is present. The following data sources are supported:
NOTE: Considerations were made here on how the caching mechanism could work. For the time being we landed on storing the query results in a Durable Object table. We can continue evaluating using the Cloudflare Cache API to do this but it seems that requires us to cache a
Responseobject and need to verify that we do this at the right point in time and are able to pull out the request to fetch the cache object as well. To move in this direction would also want to do some more testing in the maximum cache response size (per response) as well as any additional potential latency that might be added to our request. The hope would be a higher cache size per response + no incurred latency penalty.Tasks
beforeQueryCachefunction to check if the queries response is cachedafterQueryCachefunction to check eligibility to, and then cache the resultglobalConnectionvariableVerify
X-Starbase-Cacheheader)X-Starbase-Cacheheader)Before
After