Introduction:
Often, we have SPFx projects which have high transaction levels for example say a mailbox or shopping application like Amazon, or a trading site. If the backend of these types of application is SharePoint, then there is a significant chance of throttling, and one must be extremely careful while coding for such applications.
What is throttling:
SharePoint uses throttling for maintaining optimal performance and reliability of the SharePoint Online service. It limits the number of API calls or operations within a time window to prevent the overuse of resources.
Throttling within the SPO service is immutable. It cannot be adjusted on a per-tenant, application, or user basis. The rules are applied equally and consistently across the service
Most observed throttling is the result of the UserRPS threshold being exceeded. This measures the rate of incoming requests on a per-user basis. Each user has their activity measured and throttled independently. Accounts receiving throttles of this nature have exceeded the maximum allowable request volume in a unit of time and hence got throttled.
Refer page- https://aka.ms/throttling
Guidelines to avoid throttling:
The first thing is to avoid unnecessary API roundtrips, then maintain local data and track application behavior. There are several actions that can be taken to achieve that.
Maintain transaction data in local client
Try to maintain the high transaction-based data on the client side like local storage or Index DB
If the data is grid data, it is advised to maintain in Index DB else one can use local storage as well (it has data limitations so for large data use indexDB).
The data can be easily updated, added, and deleted in index DB and is useful in this high transaction scenario.
https://javascript.info/indexeddb
To update this local data, we used signalR to prevent API round trips. One can use any subscription broadcast model to get the live transaction data in the index DB completely avoiding API round trips making the application fast and at the same time preventing throttling.
https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr
Minimize API calls
Identify master data
Maintain the data that does not change frequently in the local client (could be local storage or application state), it can be fetched using API calls only once at application load. That reduces calling these APIs repeatedly wherever they are used.
Use Caching
Cache your API calls so that if the payload or data does not change the cached data can be fetched Instead of an API round trip. As we are using PnpJs we use “usecaching” in API calls to cache them. (Microsoft recommends using direct rest API or MS Graph calls than using any third parties like PnpJS as they will not provide support for those).
https://pnp.github.io/pnpjs/v1/odata/docs/caching/
Batch update
Do not update data one at a time, instead use Batch Update to prevent throttling.
https://pnp.github.io/pnpjs/concepts/batching/
Also, if possible, consolidate your updates on page unload to minimize API calls.
Tracking when the application is leading to throttle
Identify 503 and 429 errors
These errors indicate that the application is about to get throttled. So, it is better to catch these errors and log them in Log Analytics. Also, we can show some warnings in the application so that users can save their changes before it throttles.
Track Rate-Limit headers
Microsoft has modified its API to return three rate limit headers to help identify the throttling approach:
- RateLimit-Limit contains the limit in the current time window.
- RateLimit-Remaining indicates the remaining quota in the current window.
- RateLimit-Reset indicates the number of seconds until the quota is refilled.
Using these values one can come with up an approach to retry a call after some time when the throttling is approaching or simply log it to identify areas to improve that are causing throttling.
Multi-page applications
If the same page is used as in SPA that increases the chances of throttling. Microsoft recommends dividing the transactions based on most used pages to be separate SharePoint pages to minimize throttling.
How to completely avoid throttling
While designing your application it is recommended to keep highly transactional data in Azure DB to completely avoid throttling. A SharePoint backend is not recommended for highly transaction-based applications.
Conclusion
So, what do we really have here? For applications having a high level of transactions if SharePoint is the only backend available to you one must be careful while coding. Follow the guidelines mentioned above to prevent throttling as in such applications it is inevitable. But if you have an option to use some other database, it is recommended to do so, as it will save you from throttling problems which could appear as more users start using the application.
We hope you found this blog useful in learning how to effectively resolve throttling in transaction based SPFx applications. Please reach out to us so that we can put our decades of experience and expertise in Microsoft technologies and SharePoint services to help you in your organization’s Digital Transformation journey.
