Cache the ‘latest’ version of a pod.

[alloy]

The /api/v1/pods/:name/specs/latest endpoint is always performing a complicated query to figure out what the latest version is. Instead of that complicated query, we should probably just cache what the latest version is on the Pod model.

[alloy]

• Update cached version on push
• Update cached version on delete/deprecation
• Set HTTP cache headers appropriately to minimize hitting the app/db even more
• Do a data migration to add it for all the existing pods

Others?

[orta]

yeah, a cached lastest version is a good idea, in the website we've done a lot of trickery to work around this slowness.

[espadrine]

Currently shields.io calls https://trunk.cocoapods.org/api/v1/pods/SPEC/specs/latest.

We cache everything in a LRU, and use the cache:

• when the vendor times out
• when the cache was updated within 5 seconds or whatever the vendor's Cache-Control header's max-age says
• when the data changes so infrequently that 75% of responses stay accurate — although in that latter case, we still call the vendor afterwards to keep data up-to-date.

I would love to discuss what better suits vendors cache-wise, as they may have better information about how often a piece of information will be updated than my heuristics.

As I said, we read Cache-Control. It seems that respecting If-Modified-Since would be good. My cache has timestamps, so I could send If-Modified-Since. Is it faster to find out when your internal data was last updated than it is to extract the version inside it?

[alloy]

@espadrine Thanks for the info! I’ll get back to you once I’ve had the time to investigate what the best approach for us is.