One of the significant values that Apex offers to you, the developer, is the abstraction of a lot of tedious stuff you would usually have to build on your own. We front the database for you, so you don’t have to do DAO or implement triggering logic. We front the message queue for you with our asynchronous options. We front the web service gateway, so you can easily expose your logic as services. Sure, this deprives you of the opportunity to get these things wrong and waste time finding bugs in the low-level infrastructure, but it does free you up to solve the actual problems you want to solve.
Occasionally, we expose a whole new set of infrastructure to make your life easier. I get to tell you about these things, which is one of the best parts of my job.
Starting in the Winter ’16 release, Apex will expose a caching layer to you for use in your applications. We are calling this Platform Cache.
BYOC
Caching of data is primarily a performance-optimization technique, for situations where the same data will be required across multiple different transactions. Rather than recalculating or re-retrieving the information, data can be stored in an easy-to-access place—cached—and reused in later transactions. You like performant applications, so you’ve likely been setting up cache-like behavior without even knowing it.
In some sense, many of you already utilize the Visualforce view state as a “cache”. The view state passes information from the server to the client and back to the server, where it can be reused in subsequent requests. This works, but requires that you send all of the information out to the client and back to the server. When data structures become complicated and the amount of data gets large, view state becomes a bad way to share information between transactions.
Custom Settings can be used like a cache, but only for limited amounts of data. The amount of data which can be stored in custom settings is less than could be stored in the view state of 100 concurrent user sessions. That might work if you’re running your fantasy football league on the platform, but it won’t scale up to any major business need. In addition, repeatedly deleting custom setting rows when space was needed would be the opposite of fun.
Others are using the database as a poor-man’s cache. Once information is calculated, it can be saved off into an sObject, and retrieved again in a subsequent transaction. This works, but requires that you do a lot of construction work. You need to mess with org schema to create sObjects that mirror your coding needs. You might also need to deserialize the sObject data into the Apex structures you intend to use, which won’t be very performant.
These micro-cache stand-ins are the opposite of my first assertion: that Apex abstracts away the tedious stuff. We’ve left you to MacGyver your own caching process, and hope you don’t end up as MacGruber instead.
What You’re Getting – Platform Cache
Internally, our application utilizes caching for a variety of use cases. We are going to offer a slice of that cache space to you and your applications. It’s not just leftovers; we are rebuilding our cache infrastructure, and your requirements are being designed into the new cache. This is the thing we’re calling Platform Cache.
Platform Cache provides a simple API in Apex to store and retrieve items in a key/value store. It offers a built-in way to retrieve cached data in Visualforce and in declarative formulas. You interact with it very much like you interact with a map. And that’s it. You don’t have to worry about persistence, or sharding, or managing capacity, or whether or not your subsequent request was load-balanced to the same application server. We do all of that for you. You call “get” and “put”, and things are gotten and putten (putted? put in? Putin? poutine? put?) on your behalf.
Sweet.
Session Cache – For Each Of Us
The two initial Platform Cache features will be Session Cache and Org Cache.
As the name implies, the Session Cache is cache space for an individual user session. The Session Cache can help improve application performance when you have time-consuming calculations to do, or large data structures to access throughout a user’s interaction.
One example use case would be using a rules engine to display a result in a Visualforce page. The user enters some conditions, which are combined with the user’s information and fed into a rules engine. The result—say, a list of customers in a territory within 5 miles of you—is displayed to the user. As the user clicks on the different results and interacts with the records, multiple transactions are happening on the server side with each click. You don’t want to perform the initial queries and calculations to repopulate the list for every transaction; you want to cache the results. Your use case could be even more complex, where the original inputs calculate rules for valid customers, and these rules are reused repeatedly for different locations as the user scrolls around a map.
As the amount of data being passed back and forth gets larger, view state stops being a good vehicle for passing information around. This is true both because view state has a size limit and because sending data around has a cost. As you build mobile applications, the cost of sending view state goes up—in terms of both time and your users’ data plans.
To make programming easy for you, Session Cache data will be implicitly tied to each user session. You don’t need to concatenate the user session ID and the key you actually care about. You just supply the key, and the system will keep the different values connected to the correct user session. This allows you to write your code as if each user were the only one using the application.
Org Cache – For All Of Us
In addition to caching within each user session, you will be able to cache items for use by any user across the application. Org Cache is the shared cache for your entire organization.
An example where Org Cache would be useful is a navigation bar. Your user interface might have different navigation bars, populated with different menu items, for different profiles of users. You could calculate the contents of the navigation bar for each user’s session, and absorb the cost on every session. Alternatively, you could calculate the contents once for a given profile, and put the information in the Org Cache. You could then reuse this information for all users sharing that profile, without needing to do the math every time. You would only need to recalculate when the menu options changed.
Hey! Who Invalidated My Cache?
The Platform Cache feature will take care of efficient use of space. Any time you attempt to put a value into the cache, your put operation will succeed. The system will determine whether eviction is necessary in order to release space for your put. Cache content for sessions that have been idle a long time will be evicted first, keeping your more current information available in the cache.
The data you store in the cache is not intended to be 100% durable. It may be evicted by a subsequent put. It may be lost when an application server restarts. As such, you should always be prepared to reconstitute the items in the cache. While there’s an additional cost to that, it’s a lower cost than recalculating on every transaction.
Cache Management
Since you’ll know best what is expensive to recreate and what’s easy to recreate, we will provide you with cache-management tools to segment your cache space. You can set aside some space that should rarely (or never) churn, and some space that may churn quite frequently. You can create a subset of the cache space that is to be used only by one of your org’s distinct applications. The developer of that application can tweak the shape of objects being used to tune performance, without worrying that a rogue developer on a different application will get greedy (or lazy) and gobble up all the available space.
Think of cache management as being able to define multiple different caches in your org, each with a specific use. You’ll be able to access any number of these in any part of your application code.
ISVs, we haven’t forgotten about you! You will be able to make use of the Platform Cache. Your subdivision(s) of the cache will be yours to use, with a pre-specified size. You will know that your application will always have the appropriate amount of cache space to run efficiently, and not have your cache trampled by the excesses of the subscriber org. The Platform Cache will be predictable for your applications, using this segmentation approach.
In addition, my ISV friends, you will be able to share or hide your cached information. There will be mechanisms for setting the visibility of various keys, so that a managed application can use cache space which cannot be seen by subscriber code, and can simultaneously use cache space that is intended to be available to subscriber code.
With Great Power Comes Great Performance
It’s not often that we get to make a major addition to the list of infrastructure that you can access on the platform. Platform Cache will allow you to make complicated applications more performant in ways not easily possible on the platform today.
Of course, caching is not a panacea. It should not be a solution in search of a problem. Not every application will be made faster by using a cache. It is up to you, as a wise developer, to know when you have a problem in need of this particular solution. We don’t want people to just say “cache everything!” and make it so the cache does not scale to solve the problems it was intended to solve.
Thus, as with many things in the multitenant environment, there will be some limits in place to ensure that the upside described here is realized. The goal is to allow everyone to use the cache, but to ensure that use patterns are proportional to the value derived from that use.
If you have a use case for this, though, we think you’re going to like it.
There is a Session Cache pilot running in the Summer ’15 release; if you do have a use case, please reach out through your typical person you reach out to. We would like to have a small number of people make use of the feature, so we can get feedback before making it generally available. Session Cache only! Org Cache isn’t available in the Summer ’15 release pilot.