Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inbuilt caching support #1184

Closed
Badgerati opened this issue Nov 14, 2023 · 0 comments · Fixed by #1197
Closed

Inbuilt caching support #1184

Badgerati opened this issue Nov 14, 2023 · 0 comments · Fixed by #1197
Assignees
Milestone

Comments

@Badgerati
Copy link
Owner

Badgerati commented Nov 14, 2023

Pode should have inbuilt support for Caching values, plus a new $cache: scoped variable. This should support TTL on values (default 1hr), and will be auto-expired on retrieval, and $null returned.

For example, to cache a CPU value:

Add-PodeRoute -Method Get -Path '/' -ScriptBlock {
    if ($null -ne $cache:CPU) {
        Write-PodeJsonResponse -Value $cache:CPU
        return
    }

    $cpu = Get-CPU
    $cache:CPU = $cpu    # default 1hr, unless Set-PodeCache called directly

    Write-PodeJsonResponse -Value $cpu
}

When setting $cache:<name> = <value> directly, the value is cached for 1hr as default. This TTL could be explicitly set by calling Set-PodeCache -Name -Value -Ttl directly instead. Or, by calling Set-PodeCacheTtl to set a new global TTL value instead.

When $cache:<name> (or Get-PodeCache -Name) is called, and the name is present and not expired, then the value is returned. If it's not present, or expired, then $null is returned. For times when the cached value really is $null, then a Test-PodeCache -Name could be called to check if the name is present beforehand.

What would also be interesting is to see if we could add in support for custom storage (redis, dapr, etc.) - rather than just having in-memory storage. This could be done via an Add-PodeCacheStorage with scriptblock properties for retrivel/get/etc., and we could also set the storage as "default". This would allow multiple cache storages to be used; the scoped variable would use the default storage, but for other storages you would have to use a -Storage property on Set-PodeCache etc.

For example, if using a custom storage of Dapr:

$params = {
    Get = {
        param($name)
        return Invoke-RestMethod -Uri "http://localhost:3500/v1.0/state/statestore/$($name)"
    }
    Set = {
        param($name, $value, $ttl)

        $body = @(@{
            key = $name
            value = $value
            metadata = @{
                ttlInSeconds = $ttl
            }
        })

        $null = Invoke-RestMethod -Method Post -ContentType 'application/json' -Body (ConvertTo-Json -InputObject $body) -Uri 'http://localhost:3500/v1.0/state/statestore'
    }
    Test = {
        param($name)
        return ($null -ne (Invoke-RestMethod -Uri "http://localhost:3500/v1.0/state/statestore/$($name)"))
    }
    Delete = {
        param($name)
        $null = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Uri "http://localhost:3500/v1.0/state/statestore/$($name)"
    }
    Clear = {} # < not supported in dapr
}

Add-PodeCacheStorage -Name '<Name>'  @params

Likely functions to be added:

  • Get-PodeCache
  • Set-PodeCache
  • Test-PodeCache
  • Remove-PodeCache
  • Clear-PodeCache
  • Add-PodeCacheStorage
  • Remove-PodeCacheStorage
  • Get-PodeCacheStorage
  • Test-PodeCacheStorage
  • Set-PodeCacheDefaultTtl
  • Get-PodeCacheDefaultTtl
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant