Cache me if you can: What you should know before daring to set URL parameter on visualforce

Photo by John- Mark Kuznietsov http://stocksnap.io 

If someone gave me a pence for every time there was an SOQL query in an APEX Class without using Limit or a condition during a code review, I could afford a Lamborgini this month. Sigh. If only. We make it a habit of going digging for data, at the very moment we need it. The crux of this problem happens when you have chain classes which are independent of each other. Each class needs the reference from a single record and we have to query for that record every single time.

While we don't see it, every SOQL query has a cost to it, and it does not go in my Lamborghini fund, however, it should. In a recent project, we had to construct an Account 360 page that could fetch information from different integration points. The page was also called using a live telephony integration, which could pass the phone number for the account. This required an ability to keep in context the Account that was on call.

Platform Cache: Infographic

Passing the Account id in URL parameter was a valid option, however, any manipulation of that ID would be flagged as a security risk in the code. Besides querying the same data again and again during a single transaction is annoying. Clever developers (case in point) adopt the use of cookies or pass the reference as an URL parameter (Sidebar: DO NOT PUT STUFF IN URL PARAMETERS). Some people even went into Mordor and went ahead to use Custom Settings as a Cache, which makes no sense as it is as good as wasting the DML.For our problem, we adopted the use of browser cookie to maintain the account information in context.

It all comes to this- there was no proper way to keep a record in context or on the platform- until now. It was therefore when there was an announcement for Platform Cache, I wept with tears of joy. And also repeated those when I dreamed of removing the set Cookie and get Cookie from my class.

So Platform Cache API happened. The Platform Cache API lets us store and retrieve data that’s tied to Salesforce sessions or shared across your org. With Platform Cache, Salesforce adds a memory layer to its architecture. We can also control which apps can use the cache and partition it accordingly.

Here comes a bad news followed by a good one. The developer Org has no space for Cache allocated by default, but the good news is we can ask for a trial version of the same. Have provided the link at the very bottom to request your cache trial.
There are two types of Cache:

Org Cache:
The Org cache stores information that is available org-wide. It could be used instead of Custom Settings and we can save some DML statement.

Session Cache:
This is my personal favorite. Session cache can replace the horrible methods of storing information in cookies and URL parameters. We can use the session cache to store user session information that gets wiped clean every eight hours. It can be used as a cache to store the data used for the whole day.

Had a chance to brush my hands against the partition, so here is my little playground. Remember, the problem statement I talked about earlier? I had to keep the account information in context as the page kept fetching different information. The architecture for the solution was as follows:

Whenever there is a new phone call, I store the customer information in the user's cache.

Cache.OrgPartition custPart=Cache.Org.getPartition('Customer');
Account customer=[select id, Name from Account where phone=:calledID];
custPart.put('Customer', customer);



And then, every time I have to fetch the customer or want to find if the customer is on the phone call- all I do is, fetch this information from the partition.

Cache.OrgPartition custPart=Cache.Org.getPartition('Customer');
Account customerOnCall=(Account) custPart.get('customer');
System.debug('Customer on call? = ' + customerOnCall);


If my consultant is on a phone call, I get the customer information or I get a NULL value. Cache partition is going to solve a lot of transaction level problems. The use of this feature is only limited to our imagination.

What do you think? Is there a better way of using this?

Further reading:

• Josh Kaplan’s blog post introducing the Platform Cache- Salesforce Engineering
• The Platform Cache Basics Trailhead module - Good one.
• Platform Cache in the Apex Developer’s Guide  - Solid