Originally published Oct. 3, 2019
As the Product Manager for the Brightspace API, I have had the opportunity to meet with many customers and partners to learn about the wide variety of integrations and solutions that have been developed. Over this timeframe, we have also been looking at Brightspace API usage data. For those who attended my session at Fusion 2019, you may recall that this anecdotal and analytic data has made clear to me the types of API solutions that are being developed (Integration, Automation, Data, Custom UX & Innovation). This data has also informed us that Brightspace API usage has increased significantly over the years, which is something that we are all very excited about.
As for any API product, increased usage is a double-edged sword. It shows us that our API is providing value to many of you. However, the downside is that we have seen scenarios of extremely high API usage which have caused a negative impact on the performance of Brightspace servers. Spikes in very high API usage do have an impact on server performance.
Our goal as a SaaS vendor is to provide you with application stability and up-time. Therefore we have decided to actively investigate how to collaborate with customers and partners to ensure that API usage can continue to grow while at the same time we prevent performance issues.
API Rate Logging = Now
Our core initial investigation is to log scenarios where a specific Brightspace API App has performed a high amount of API calls in a short period of time. The data that we have collected thus far has already been insightful. This data has provided us with a better understanding of the API route patterns being used for high-volume solutions. This has allowed us to:
- Initiate meaningful conversations with customers regarding API development best practices. The goal of these meetings is to find ways to develop more efficient and scalable API solutions together.
- Identify opportunities to improve the efficiency of existing API's.
- Investigate the development of bulk API's which would decrease the number of incoming API calls.
- Consider what an acceptable amount of API calls performed by an App might be.
API Rate Limiting = Near Future
All of the above points are helping D2L determine ways to allow our customers and partners to continue to develop amazing Brightspace solutions while maintaining the stability of Brightspace. The last point is an important one as we believe that we can determine what an acceptable amount of API calls would be for a well-designed application.
As our API Rate Logging improves we will be using this data to determine an "appropriate use" API usage threshold. This threshold would be based on having a minimal impact on existing solutions while preventing solutions from negatively impacting Brightspace performance. Our plan is to use this as part of an API Rate Limiting solution. Such a solution would:
- Block API traffic which exceeds the acceptable use threshold
- Inform a developer when API traffic has been blocked
- Inform a developer of the process to take to be allowed to continue to perform API calls
When is this happening?
API Rate Logging was turned ON for all D2L customers in October 2019.
API Rate Limiting was turned ON for all new D2L customers on December 16, 2019.
API Rate Limiting was turned ON for all existing D2L customers non-Production sites on Monday, March 9th, 2020.
API Rate Limiting is planned to be turned ON for all existing D2L customers Production sites on Monday, June 8th, 2020.
How to start preparing for API Rate Limiting
Monitor your Brightspace API use
Review the code that you have already written to see if you can reduce the volume of calls you are making. Are you using API calls to retrieve static data that would be available to you through datasets? Are there newer Brightspace API routes available which would make your code more efficient? Consider logging your API calls so you can get more clarity on your API usage spikes.
Roll out your own API Throttling solution
Work with your technical staff to determine if an API Gateway and/or an Enterprise Service Bus solution makes sense for this and other reasons.
Preparing Code
We will be sharing more details regarding the implementation of our Rate Limiting solution over the upcoming months. We are confident in saying that our solution will block API calls which exceed the acceptable use threshold. When the rate limit solution is implemented, you will know you have experienced an API Rate Limit event when you receive a 429 "Too Many Requests" response message. This response will include information on how long you will have to wait until you can retry sending API calls again.
Send us Feedback
Comment within this article if you have questions. Monitor the Brightspace Developer Community as we will be publishing more details as this solution evolves. And as always, let us know, through the Product Idea Exchange, of ways we can improve the Brightspace API to allow you to make your code more efficient. If you aren't finding the answer to your question then feel free to connect with your D2L TAM and/or CSM.
What else do I need to know?
Like other Brightspace features, our expectation is that API Rate Logging and Limiting will evolve based on client feedback and data analysis. As the main goal of implementing these solutions is the stability of your Brightspace experience, we will continue to provide updates to API Rate Logging & Limiting based on this goal. Updates will be communicated through the Brightspace Community, Valence Documentation, the 90 Day Review/Preview, as well as through your D2L TAM/CSM.
Additional Resources
API Rate Logging/Limiting - FAQ