Update how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online.md (SharePoint#7031)

Remove a note that contains incorrect information about how throttling treats app+user traffic.
Mention Microsoft Graph as a means to reduce throttling.

Author: guzi99

docs/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online.md

@@ -45,9 +45,6 @@ If the offending process continues to exceed usage limits, SharePoint Online mig
 In addition to throttling by user account, limits are also applied to each application. Every application in SharePoint Online has its own available resources, but multiple applications running against the same tenant ultimately share from the same resource bucket and in rare occurrences can cause rate limiting.
 In these cases, SharePoint Online will attempt to prioritize interactive user requests over background activities.
 
-> [!NOTE]
-> Notice that there is difference between AppOnly authentication and Delegated authentication when making use of Applications when it comes to throttling. When making use of the delegated approach, throttling is applied on an user-basis and not the used application. When making use of the AppOnly way of authenticating, throttling is applied on application-basis.  
-
 ## Common throttling scenarios in SharePoint Online
 
 The most common causes of per-user throttling in SharePoint Online are client-side object model (CSOM) or Representational State Transfer (REST) code that performs too many actions too frequently.
@@ -75,7 +72,7 @@ The most common causes of per-user throttling in SharePoint Online are client-si
 
 Setting and publishing exact throttling limits sounds straightforward, but in fact it would result in more restrictive limits. We continually monitor resource usage on SharePoint Online. Depending on usage, we fine-tune thresholds so users can consume the maximum number of resources without degrading the reliability and performance of SharePoint Online.
 
-That's why it's so important for your CSOM or REST code to honor the `Retry-After` HTTP header value; this lets your code run as fast as possible on any given day, and it lets your code back off "just enough" if it hits throttling limits. The code samples later in this article show you how to use the `Retry-After` HTTP header.
+That's why it's so important for your code to honor the `Retry-After` HTTP header value; this lets your code run as fast as possible on any given day, and it lets your code back off "just enough" if it hits throttling limits. The code samples later in this article show you how to use the `Retry-After` HTTP header.
 
 ## Search query volume limits when using app-only authentication with Sites.Read.All permission
 
@@ -89,9 +86,12 @@ As we scale our system, we realize the importance of hardening the system to run
 
 - Reduce the number of operations per request
 - Reduce the frequency of calls
+- Choose Microsoft Graph APIs over CSOM and REST APIs when possible
 - Decorate your traffic so we know who you are (see section on traffic decoration best practice more on that below)
 - Leverage the `Retry-After` HTTP header
 
+Microsoft Graph is cloud born APIs that have the latest improvements and optimizations. In general, Microsoft Graph consumes less resource than CSOM and REST to achieve the same functionality. Hence, adopting Microsoft Graph can improve application's performance and reduce throttling.
+
 If you do run into throttling, we require leveraging the `Retry-After` HTTP header to ensure minimum delay until the throttle is removed.
 
 The `Retry-After` HTTP header is the fastest way to handle being throttled because SharePoint Online dynamically determines the right time to try again. In other words, aggressive retries work against you because even though the calls fail, they still accrue against your usage limits. Following the `Retry-After` HTTP header will ensure the shortest delay.