Does the same caching algorithm apply to storable actions and @AuraEnabled(caching=true)

Question

In Aura components we used to call action.setStorable() on the client side. For LWC (and optionally Aura) we now cache query results by setting @AuraEnabled(cacheable=true) on the server side.

Is the behavior / algorithm used by cacheable=true outlined anywhere? The documentation on the @AuraEnabled annotation provides the following vague information.

Marking a method as storable (cacheable) improves your component’s performance by quickly showing cached data from client-side storage without waiting for a server trip. If the cached data is stale, the framework retrieves the latest data from the server.

The docs on the lifecycle on storable Aura actions are more detailed and outline the possibility that the callback executes twice if it's a cache hit that requires a refresh. I'm wondering if those same rules apply to Aura actions that call an @AuraEnabled(cacheable=true) method, and if the same rules apply to wire service when the adapter is an Apex method.

Thanks!

Answer 1

Yes, @AuraEnabled(cacheable=true) and setStorable are the same thing. As of API 44.0, Storable Actions have been replaced with @AuraEnabled(cacheable=true). The change was made so that the act of caching would be centralized instead of requiring it in multiple places in JS.

Documentation

Prior to API version 44.0, to cache data returned from an Apex method, you had to call setStorable() in JavaScript code on every action that called the Apex method. For API version of 44.0 or higher, you can mark the Apex method as storable (cacheable) and get rid of any setStorable() calls in JavaScript code. The Apex annotation approach is better because it centralizes your caching notation for a method in the Apex class.

Also:

For storable actions in the cache, the framework returns the cached response immediately and also refreshes the data if it’s stale. Therefore, storable actions might have their callbacks invoked more than once: first with cached data, then with updated data from the server.

Note that this only applies to stale cache hits. If there is a cache miss, only one call is made, and if the cache is determined not to be stale, only one call is made.