Flashm is a Lightning Web Component framework to reduce Apex server calls and enhance the performance of data fetching for Lightning Web Components. The framework stores the promises at the browser’s tab and it can be reused without making the almost no server call.
Flashm works great when we need to retrieve the same data in a low network or no network.
If you are from Aura Component background then you can relate it to Storable Actions from Aura. Although Flashm is not the same as Storable Actions but it serves the quite same output.
Note: The same thing can be done just by adding cacheable=true to apex methods. One can use Flashm if need to have control when to refresh data.
What are the differences:
- cacheable=true works quite differently as it will make server call if data has been stale for a few seconds. But Flashm won’t make server call in any condition because of cache doesn’t refresh automatically.
- cacheable=true gives network error when data has been stale and the network is entirely off because it tries from server to get data but Flashm will provide the data.
- Flashm provides the methods for when to flush data and get new data.
Assume that we are loading configuration data from sObject/Custom Settings. We want to use this data on various place like Utility Bar, Multiple pages throughout the app. We are having 5 to 6 Lightning Web Components on the page. These can be in the hierarchy, Utility Bar and individually placed on the page. All of these are using basic configuration and making server calls for the same data. After using Flashm, this data will be loaded for only one time and can be used across all pages.
In my case, I was having 6-7 Lightning Web Components on the page and 4 LWCs in the utility bar with having 6 lightning page tabs. If I don’t use Flashm then it would cost me 60 Apex Server Calls and these get increased as the user navigates to the App many times. It can go from 10 to 100 easily. After using Flashm, It is only and only One.
How it Works and Why is Super Fast?
Flashm works as middleware between Lightning Web Component and Apex Calls. It provides the memory to store the blocks and cells. You invoke Flashm then Flashm invokes the Apex call. Flashm is based on Blocks and Cells.
Block: is the address that is same for all the same Apex methods. A block contains multiple cells.
Cell: Cell is the place where the parameters and promises get stored. Cells provide virtual memory. Parameters work as a unique address for every cell in the block.
As described in the diagram, Because every apex call is first checked in the Flashm memory. If a promise is found in the Flashm memory then it returns from the here instead of going to the server.
- Superfast as it uses the Flashm memory to store the promises and return data if needed instead of making the server call.
- You have control to erase the cell, block, and entire Flashm memory.
- If Flashm memory contains data and apex call is requested then it can be used without network as well. Ex: Can be used at Kiosks where the app has limited searches and no network sometimes.
- Reduce the Server load. Provide more lighting to your lightning app.
Considerations and Limitation
- Don’t use when dealing with large data.
- Don’t use to commit/DML to the server. Must be used to retrieve the data from the server.
- Take care while naming the Block address. Don’t use the same name for two different kinds of Apex methods.
- Should use flushCell in catch statements. So in case of error, Flashm doesn’t store the error. In the next call, it tries a server call to retrieve success result.
- Should not be used with cacheable methods.
Demo Code: Gist