Add "cache identifier" argument to .GetRemote

[regisphilibert]

Currently users grabbing data from an API have to rely on file caching to ensure the API is not solicited on every build. (To avoid limitations but also slower builds)
To refresh the response every hour, set up a hourly build and set your cache settings to:

caches:
  getresource:
    maxAge: 1h

Then file caching setting of Hugo identifies a cached "response" with a hashed concatenation of the request's URL and the passed options (headers, body etc...)

This presents several problem.

1. Some API requires the date and time to be included in the authorization header for extra security. This means the .GetRemote options will always be different thus producing a unique cache identifier every time.
2. Cache options are shared by ever request. Every .GetRemote call will be subject to the same maxAge for example. No way to set one API call to refresh every day, and another one every hour.

Proposal

Add a third and optional parameter to .GetRemote to pass on a cache identifier.

Not only will it solves 1. by giving control to users on the cache identifier (omitting some options), but it will also give more control to users, thus bypassing the 2. limitation.

Cache for approximately one hour by including the current time (to the hour) in the cache id:

$cache_id := print $url (time.Format "2006-01-02T15")
$request := resource.GetRemote $url $options $cache_id

Cache for approximately one day by including the current date (to the day) in the cache id:

$cache_id := print $url (time.Format "2006-01-02")
$request := resource.GetRemote $url $options $cache_id

[bep]

It would also move all the critical directories to the top of the list which is a nice bonus.

What?

I suggest you append a cache-buster to the URL, e.g. https://example.org/api?hugo_cachebuster=12345.

[regisphilibert]

My last comment was in the wrong issue.

I suggest you append a cache-buster to the URL, e.g. https://example.org/api?hugo_cachebuster=12345.

Yes that's a fair for point for 2. but will not solve 1.

[bep]

Yes that's a fair for point for 2. but will not solve 1.

OK, I misunderstood -- you want it to be cached ... I guess we could consider adding a cacheKey to the options map or something. But you could probably also solve this by hiding the header creating behind partialCached.

[regisphilibert]

But you could probably also solve this by hiding the header creating behind partialCached.

That would only cache the output on that one build scope though right?

[ghost]

(Sidenote: I was using cron to update the GA script hosted locally on WP once a day. Will this feature do a similar thing if a build is made with Hugo, e.g. if set for a day, any time after one day?)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.