Add three glossary pages related to rate limiting (#35406)

* Add three glossary pages related to rate limiting

* Apply suggestions from code review

Co-authored-by: Brian Thomas Smith <brian@smith.berlin>

---------

Co-authored-by: Brian Thomas Smith <brian@smith.berlin>

files/en-us/glossary/debounce/index.md

@@ -0,0 +1,26 @@
+---
+title: Debounce
+slug: Glossary/Debounce
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+**Debouncing**, in the context of programming, means to "batch" all operations requested during a specific interval into a single invocation.
+
+Debouncing is very similar to {{glossary("throttle", "throttling")}}. The key difference is that throttling enforces limits on continuous operations, while debouncing waits for invocations to stop for a specific time to consolidate many noisy invocations into one single invocation.
+
+A typical use case of debouncing is when responding to user input. When the user is typing, no other action should be taken to avoid the UI becoming laggy. When the user pauses typing, we can start processing the input, such as filtering results, giving suggestions, etc. If the function `search` is debounced by 10 milliseconds, it means:
+
+1. The first call to `search` is known as the _leading edge_.
+2. For every next call to `search`, if it is within 10 milliseconds from the previous call, it is in the same "batch" as the previous call.
+3. After 10 milliseconds have elapsed from the last call to `search`, if no other calls have happened, we have reached the _trailing edge_.
+
+Usually, `search` is executed once on the trailing edge only, although sometimes it might be executed on the leading edge, or even both edges, depending on the specific use case. If executed on both edges, the debouncing implementation usually also ensures that the next leading edge invocation doesn't fire at least 10 milliseconds after the previous trailing edge.
+
+## See also
+
+- Glossary terms:
+  - {{Glossary("Throttle")}}
+  - {{Glossary("Rate limit")}}
+- [Debouncing and Throttling Explained Through Examples](https://css-tricks.com/debouncing-throttling-explained-examples/) on CSS-Tricks (April 6, 2016)

files/en-us/glossary/rate_limit/index.md

@@ -0,0 +1,19 @@
+---
+title: Rate limit
+slug: Glossary/Rate_limit
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+In computing, especially in networking, **rate limiting** means controlling how many operations can be performed in a given amount of time, usually to avoid overloading the system and causing performance degredation. For example, a server might limit the number of requests it will accept from a single client in a given time period, which not only optimizes the server's overall performance but also mitigates attacks like {{glossary("DoS attack")}}.
+
+Rate limiting is typically synonymous with {{glossary("throttle", "throttling")}}, although {{glossary("debounce", "debouncing")}} is another viable strategy which provides better semantics and user experience in certain cases.
+
+## See also
+
+- Glossary terms:
+  - {{Glossary("Debounce")}}
+  - {{Glossary("Throttle")}}
+- {{HTTPStatus("429", "429 Too Many Requests")}}
+- [What is rate limiting? | Rate limiting and bots](https://www.cloudflare.com/en-gb/learning/bots/what-is-rate-limiting/) on cloudflare.com

files/en-us/glossary/throttle/index.md

@@ -0,0 +1,30 @@
+---
+title: Throttle
+slug: Glossary/Throttle
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+**Throttling** originally meant slowing down the rate of fluid flow using an obstruction. In the context of programming, it refers to slowing down a process such that an operation can only be performed at a certain rate.
+
+Throttling is very similar to {{glossary("debounce", "debouncing")}}. The key difference is that when invocations happen continuously, throttling ensures that the operation is still performed at a certain maximum rate, while debouncing waits indefinitely until the invocations stop for a certain amount of time.
+
+A typical use case of debouncing is when synchronizing with another constantly-updating state. Consider a function `onScrolled`, which listens for the [`scroll`](/en-US/docs/Web/API/Document/scroll_event) event. The `scroll` event may fire as often as every pixel scrolled, so the function will be called in very short intervals. If `onScrolled` is computationally expensive, earlier invocations might block later invocations from happening on time, or block other things from executing in the meantime, leading to a noticeable {{glossary("jank")}}. In this case, we can throttle `onScrolled`, such that it can only be called at most once every 10 milliseconds:
+
+1. The first call to `onScrolled` is known as the _leading edge_.
+2. For every next call to `onScrolled`, if it is within 10 milliseconds from the first call, it is in the same "batch" as the first call.
+3. After 10 milliseconds have elapsed from the first call to `onScrolled`, we have reached the _trailing edge_.
+
+Usually, `onScrolled` is executed once on the leading edge only, although sometimes it might be executed on the trailing edge, or even both edges, depending on the specific use case. If executed on both edges, the throttling implementation usually also ensures that the next leading edge invocation doesn't fire at least 10 milliseconds after the previous trailing edge.
+
+Via throttling, the effect of `onScrolled` is still continuously updated and applied — for example, if it moves another DOM element based on the document's scroll position, that DOM element is still continuously moved while the page is scrolling — but it isn't executed more often than necessary.
+
+{{glossary("Network throttling")}} means to simulate a slower network connection by only allowing a certain amount of data to be transferred at a time. _Throttling a timer_ means to coarsen the timer's precision such that when reading the timer (such as {{jsxref("Date.now()")}}) continuously, the timer's value only changes at a certain maximum rate. Both are specific applications of the general concept of throttling.
+
+## See also
+
+- Glossary terms:
+  - {{Glossary("Debounce")}}
+  - {{Glossary("Rate limit")}}
+- [Debouncing and Throttling Explained Through Examples](https://css-tricks.com/debouncing-throttling-explained-examples/) on CSS-Tricks (April 6, 2016)

files/en-us/learn/server-side/django/authentication/index.md

@@ -30,7 +30,7 @@ In this tutorial, we'll show you how to allow users to log in to your site with
 Django provides an authentication and authorization ("permission") system, built on top of the session framework discussed in the [previous tutorial](/en-US/docs/Learn/Server-side/Django/Sessions), that allows you to verify user credentials and define what actions each user is allowed to perform. The framework includes built-in models for `Users` and `Groups` (a generic way of applying permissions to more than one user at a time), permissions/flags that designate whether a user may perform a task, forms and views for logging in users, and view tools for restricting content.
 
 > [!NOTE]
-> According to Django the authentication system aims to be very generic, and so does not provide some features provided in other web authentication systems. Solutions for some common problems are available as third-party packages. For example, throttling of login attempts and authentication against third parties (e.g. OAuth).
+> According to Django the authentication system aims to be very generic, and so does not provide some features provided in other web authentication systems. Solutions for some common problems are available as third-party packages. For example, {{glossary("throttle", "throttling")}} of login attempts and authentication against third parties (e.g. OAuth).
 
 In this tutorial, we'll show you how to enable user authentication in the [LocalLibrary](/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website) website, create your own login and logout pages, add permissions to your models, and control access to pages. We'll use the authentication/permissions to display lists of books that have been borrowed for both users and librarians.
 

files/en-us/web/api/document/scroll_event/index.md

@@ -30,7 +30,7 @@ A generic {{domxref("Event")}}.
 
 ### Scroll event throttling
 
-Since `scroll` events can fire at a high rate, the event handler shouldn't execute computationally expensive operations such as DOM modifications. Instead, it is recommended to throttle the event using {{DOMxRef("Window.requestAnimationFrame()", "requestAnimationFrame()")}}, {{DOMxRef("setTimeout()")}}, or a {{DOMxRef("CustomEvent")}}, as follows.
+Since `scroll` events can fire at a high rate, the event handler shouldn't execute computationally expensive operations such as DOM modifications. Instead, it is recommended to {{glossary("throttle")}} the event using {{DOMxRef("Window.requestAnimationFrame()", "requestAnimationFrame()")}}, {{DOMxRef("setTimeout()")}}, or a {{DOMxRef("CustomEvent")}}, as follows.
 
 Note, however, that input events and animation frames are fired at about the same rate, and therefore the optimization below is often unnecessary. This example optimizes the `scroll` event for `requestAnimationFrame`.
 

files/en-us/web/api/element/scroll_event/index.md

@@ -28,7 +28,7 @@ A generic {{domxref("Event")}}.
 ## Examples
 
 The following examples show how to use the `scroll` event with an event listener and with the `onscroll` event handler property.
-The {{DOMxRef("setTimeout()")}} method is used to throttle the event handler because `scroll` events can fire at a high rate.
+The {{DOMxRef("setTimeout()")}} method is used to {{glossary("throttle")}} the event handler because `scroll` events can fire at a high rate.
 For additional examples that use {{DOMxRef("Window.requestAnimationFrame()", "requestAnimationFrame()")}}, see the `Document` {{domxref("Document/scroll_event", "scroll")}} event page.
 
 ### Using `scroll` with an event listener

files/en-us/web/api/htmlinputelement/search_event/index.md

@@ -12,7 +12,7 @@ browser-compat: api.HTMLInputElement.search_event
 
 The **`search`** event is fired when a search is initiated using an {{HTMLElement("input")}} element of `type="search"`.
 
-There are several ways a search can be initiated, such as by pressing <kbd>Enter</kbd> while the {{HTMLElement("input")}} is focused, or, if the [`incremental`](/en-US/docs/Web/HTML/Element/input#incremental) attribute is present, after a UA-defined timeout elapses since the most recent keystroke (with new keystrokes resetting the timeout so the firing of the event is debounced).
+There are several ways a search can be initiated, such as by pressing <kbd>Enter</kbd> while the {{HTMLElement("input")}} is focused, or, if the [`incremental`](/en-US/docs/Web/HTML/Element/input#incremental) attribute is present, after a UA-defined timeout elapses since the most recent keystroke (with new keystrokes resetting the timeout so the firing of the event is {{glossary("debounce", "debounced")}}).
 
 Current UA implementations of `<input type="search">` have an additional control to clear the field. Using this control also fires the `search` event. In that case the `value` of the {{HTMLElement("input")}} element will be the empty string.
 

files/en-us/web/http/browser_detection_using_the_user_agent/index.md

@@ -132,7 +132,7 @@ The user can flip their mobile device on its side, changing the width and height
 Or, there might be some weird flip-phone-like device thing in the future where flipping it out extends the screen.
 Do not be the developer having a headache over how to deal with the flip-phone-like device thing.
 Never be satisfied with your webpage until you can open up the dev tools side panel and resize the screen while the webpage looks smooth, fluid, and dynamically resized.
-The simplest way to do this is to separate all the code that moves content around based on screen size to a single function that is called when the page is loaded and at each [resize](/en-US/docs/Web/API/Window/resize_event) event thereafter. If there is a lot calculated by this layout function before it determines the new layout of the page, then consider debouncing the event listener such that it is not called as often.
+The simplest way to do this is to separate all the code that moves content around based on screen size to a single function that is called when the page is loaded and at each [resize](/en-US/docs/Web/API/Window/resize_event) event thereafter. If there is a lot calculated by this layout function before it determines the new layout of the page, then consider {{glossary("debounce", "debouncing")}} the event listener such that it is not called as often.
 Also note that there is a huge difference between the media queries `(max-width: 25em)`, `not all and (min-width: 25em)`, and `(max-width: 24.99em)`: `(max-width: 25em)` excludes `(max-width: 25em)`, whereas `not all and (min-width: 25em)` includes `(max-width: 25em)`.
 `(max-width: 24.99em)` is a poor man's version of `not all and (min-width: 25em)`: do not use `(max-width: 24.99em)` because the layout _might_ break on very high font sizes on very high definition devices in the future.
 Always be very deliberate about choosing the right media query and choosing the right `>=`, `<=`, `>`, or `<` in any corresponding JavaScript because it is very easy to get these mixed up, resulting in the website looking wonky right at the screen size where the layout changes.

files/en-us/web/http/status/429/index.md

@@ -8,7 +8,7 @@ spec-urls: https://www.rfc-editor.org/rfc/rfc6585#section-4
 {{HTTPSidebar}}
 
 The HTTP **`429 Too Many Requests`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates the client has sent too many requests in a given amount of time.
-This mechanism of asking the client to slow down the rate of requests is commonly called "rate limiting".
+This mechanism of asking the client to slow down the rate of requests is commonly called "{{glossary("rate limit", "rate limiting")}}".
 
 A {{HTTPHeader("Retry-After")}} header may be included to this response to indicate how long a client should wait before making the request again.
 

files/en-us/web/security/index.md

@@ -102,7 +102,7 @@ Here are some other tips for providing secure logins:
   > [!NOTE]
   > Some phishing sites can be very sophisticated and hard to distinguish from a real website. You should therefore educate your users to not trust random links in emails and SMS messages. If they receive a message along the lines of "Urgent, you need to log in now to resolve an issue", they should go to the site directly in a new tab and try logging in directly rather than clicking the link in the message. Or they could phone or email you to discuss the message they received.
 
-- Protect against brute force attacks on login pages with [rate limiting](https://www.cloudflare.com/en-gb/learning/bots/what-is-rate-limiting/), account lockouts after a certain number of unsuccessful attempts, and [CAPTCHA challenges](https://en.wikipedia.org/wiki/CAPTCHA).
+- Protect against brute force attacks on login pages with {{glossary("rate limit", "rate limiting")}}, account lockouts after a certain number of unsuccessful attempts, and [CAPTCHA challenges](https://en.wikipedia.org/wiki/CAPTCHA).
 - Manage user login sessions with unique [session IDs](https://en.wikipedia.org/wiki/Session_ID), and automatically log out users after periods of inactivity.
 
 ### Don't include sensitive data in URL query strings