docs(guides): grammar and spelling fixes (fastify#5947)

* docs(guides): grammar and spelling fixes

* docs(guides): stop note being treated as header

Author: Fdawgs

docs/Guides/Benchmarking.md

@@ -1,17 +1,17 @@
 <h1 align="center">Fastify</h1>
 
 ## Benchmarking
-Benchmarking is important if you want to measure how a change can affect the
-performance of your application. We provide a simple way to benchmark your
+Benchmarking is important if you want to measure how a change can affect your
+application's performance. We provide a simple way to benchmark your
 application from the point of view of a user and contributor. The setup allows
 you to automate benchmarks in different branches and on different Node.js
 versions.
 
 The modules we will use:
-- [Autocannon](https://github.com/mcollina/autocannon): A HTTP/1.1 benchmarking
+- [Autocannon](https://github.com/mcollina/autocannon): An HTTP/1.1 benchmarking
   tool written in node.
 - [Branch-comparer](https://github.com/StarpTech/branch-comparer): Checkout
-  multiple git branches, execute scripts and log the results.
+  multiple git branches, execute scripts, and log the results.
 - [Concurrently](https://github.com/kimmobrunfeldt/concurrently): Run commands
   concurrently.
 - [Npx](https://github.com/npm/npx): NPM package runner used to run scripts

docs/Guides/Contributing.md

@@ -6,9 +6,10 @@ receive your support and knowledge. This guide is our attempt to help you help
 us.
 
 > ## Note
-> This is an informal guide. Please review the formal [CONTRIBUTING
-> document](https://github.com/fastify/fastify/blob/main/CONTRIBUTING.md) for
-> full details and our [Developer Certificate of
+> This is an informal guide. For full details, please review the formal
+> [CONTRIBUTING 
+> document](https://github.com/fastify/fastify/blob/main/CONTRIBUTING.md)
+> our [Developer Certificate of
 > Origin](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin).
 
 ## Table Of Contents
@@ -50,7 +51,7 @@ should expect from others):
 * We have a [Code of
   Conduct](https://github.com/fastify/fastify/blob/main/CODE_OF_CONDUCT.md). You
   must adhere to it to participate in this project.
-* If you open a pull request, please ensure that your contribution passes all
+* If you open a pull request, please ensure your contribution passes all
   tests. If there are test failures, you will need to address them before we can
   merge your contribution.
 
@@ -79,7 +80,7 @@ https://github.com/github/opensource.guide/blob/2868efbf0c14aec821909c19e210c360
 
 Please adhere to the project's code and documentation style. Some popular tools
 that automatically "correct" code and documentation do not follow a style that
-conforms to the styles this project uses. Notably, this project uses
+conforms to this project's styles. Notably, this project uses
 [StandardJS](https://standardjs.com) for code formatting.
 
 [![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/fastify/fastify)

docs/Guides/Database.md

@@ -245,7 +245,7 @@ for Postgres, MySQL, SQL Server and SQLite. For MongoDB migrations, please check
 #### [Postgrator](https://www.npmjs.com/package/postgrator)
 
 Postgrator is Node.js SQL migration tool that uses a directory of SQL scripts to
-alter the database schema. Each file in a migrations folder need to follow the
+alter the database schema. Each file in a migrations folder needs to follow the
 pattern: ` [version].[action].[optional-description].sql`.
 
 **version:** must be an incrementing number (e.g. `001` or a timestamp).

docs/Guides/Delay-Accepting-Requests.md

@@ -77,8 +77,8 @@ server.get('/ping', function (request, reply) {
 })
 
 server.post('/webhook', function (request, reply) {
-  // It's good practice to validate webhook requests really come from
-  // whoever you expect. This is skipped in this sample for the sake
+  // It's good practice to validate webhook requests come from
+  // who you expect. This is skipped in this sample for the sake
   // of simplicity
 
   const { magicKey } = request.body
@@ -448,10 +448,10 @@ have the possibility of giving the customer meaningful information, like how
 long they should wait before retrying the request. Going even further, by
 issuing a [`503` status
 code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503) we're
-signaling to our infrastructure components (namely load balancers) we're still
-not ready to take incoming requests and they should redirect traffic to other
-instances, if available, besides in how long we estimate that will be solved.
-All of that in a few simple lines!
+signaling to our infrastructure components (namely load balancers) that we're
+still not ready to take incoming requests and they should redirect traffic to
+other instances, if available. Additionally, we are providing a `Retry-After`
+header with the time in milliseconds the client should wait before retrying.
 
 It's noteworthy that we didn't use the `fastify-plugin` wrapper in the `delay`
 factory. That's because we wanted the `onRequest` hook to only be set within
@@ -524,14 +524,14 @@ Retry-After: 5000
 }
 ```
 
-Then we attempt a new request (`req-2`), which was a `GET /ping`. As expected,
+Then we attempted a new request (`req-2`), which was a `GET /ping`. As expected,
 since that was not one of the requests we asked our plugin to filter, it
-succeeded. That could also be used as means of informing an interested party
+succeeded. That could also be used as a means of informing an interested party
 whether or not we were ready to serve requests (although `/ping` is more
 commonly associated with *liveness* checks and that would be the responsibility
 of a *readiness* check -- the curious reader can get more info on these terms
 [here](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes))
-with the `ready` field. Below is the response for that request:
+with the `ready` field. Below is the response to that request:
 
 ```sh
 HTTP/1.1 200 OK
@@ -547,7 +547,7 @@ Keep-Alive: timeout=5
 }
 ```
 
-After that there were more interesting log messages:
+After that, there were more interesting log messages:
 
 <!-- markdownlint-disable -->
 ```sh

docs/Guides/Fluent-Schema.md

@@ -55,7 +55,7 @@ fastify.post('/the/url', { schema }, handler)
 
 ### Reuse
 
-With `fluent-json-schema` you can manipulate your schemas more easily and
+With `fluent-json-schema`, you can manipulate your schemas more easily and
 programmatically and then reuse them thanks to the `addSchema()` method. You can
 refer to the schema in two different manners that are detailed in the
 [Validation and

docs/Guides/Getting-Started.md

@@ -106,7 +106,7 @@ of your code.
 Fastify offers an easy platform that helps to solve all of the problems outlined
 above, and more!
 
-> ## Note
+> **Note**
 > The above examples, and subsequent examples in this document, default to
 > listening *only* on the localhost `127.0.0.1` interface. To listen on all
 > available IPv4 interfaces the example should be modified to listen on
@@ -417,7 +417,7 @@ In this way, you will always have access to all of the properties declared in
 the current scope.
 
 As discussed previously, Fastify offers a solid encapsulation model, to help you
-build your application as single and independent services. If you want to
+build your application as independent services. If you want to
 register a plugin only for a subset of routes, you just have to replicate the
 above structure.
 ```
@@ -552,7 +552,7 @@ an amazing [ecosystem](./Ecosystem.md)!
 <a id="test-server"></a>
 
 Fastify does not offer a testing framework, but we do recommend a way to write
-your tests that use the features and architecture of Fastify.
+your tests that uses the features and architecture of Fastify.
 
 Read the [testing](./Testing.md) documentation to learn more!
 

docs/Guides/Index.md

@@ -19,7 +19,7 @@ This table of contents is in alphabetical order.
   practical guide on detecting if and when a client aborts a request.
 + [Ecosystem](./Ecosystem.md): Lists all core plugins and many known community
   plugins.
-+ [Fluent Schema](./Fluent-Schema.md): Shows how writing JSON Schema can be
++ [Fluent Schema](./Fluent-Schema.md): Shows how JSON Schema can be
   written with a fluent API and used in Fastify.
 + [Getting Started](./Getting-Started.md): Introduction tutorial for Fastify.
   This is where beginners should start.

docs/Guides/Migration-Guide-V4.md

@@ -210,7 +210,7 @@ fastify.get('/posts/:id?', (request, reply) => {
 The [variadic signature](https://en.wikipedia.org/wiki/Variadic_function) of the
 `fastify.listen()` method is now deprecated.
 
-Prior to this release, the following invocations of this method were valid:
+Before this release, the following invocations of this method were valid:
 
   - `fastify.listen(8000)`
   - `fastify.listen(8000, ‘127.0.0.1’)`

docs/Guides/Plugins-Guide.md

@@ -71,8 +71,8 @@ order of plugins. *How?* Glad you asked, check out
 [`avvio`](https://github.com/mcollina/avvio)! Fastify starts loading the plugin
 __after__ `.listen()`, `.inject()` or `.ready()` are called.
 
-Inside a plugin you can do whatever you want, register routes, utilities (we
-will see this in a moment) and do nested registers, just remember to call `done`
+Inside a plugin you can do whatever you want, register routes and utilities (we
+will see this in a moment), and do nested registers, just remember to call `done`
 when everything is set up!
 ```js
 module.exports = function (fastify, options, done) {
@@ -117,7 +117,7 @@ Now you can access your utility just by calling `fastify.util` whenever you need
 it - even inside your test.
 
 And here starts the magic; do you remember how just now we were talking about
-encapsulation? Well, using `register` and `decorate` in conjunction enable
+encapsulation? Well, using `register` and `decorate` in conjunction enables
 exactly that, let me show you an example to clarify this:
 ```js
 fastify.register((instance, opts, done) => {
@@ -137,7 +137,7 @@ Inside the second register call `instance.util` will throw an error because
 `util` exists only inside the first register context.
 
 Let's step back for a moment and dig deeper into this: every time you use the
-`register` API, a new context is created which avoids the negative situations
+`register` API, a new context is created that avoids the negative situations
 mentioned above.
 
 Do note that encapsulation applies to the ancestors and siblings, but not the
@@ -202,7 +202,7 @@ a utility that also needs access to the `request` and `reply` instance,
 a function that is defined using the `function` keyword is needed instead
 of an *arrow function expression*.
 
-In the same way you can do this for the `request` object:
+You can do the same for the `request` object:
 ```js
 fastify.decorate('getHeader', (req, header) => {
   return req.headers[header]
@@ -395,7 +395,7 @@ As we mentioned earlier, Fastify starts loading its plugins __after__
 have been declared. This means that, even though the plugin may inject variables
 to the external Fastify instance via [`decorate`](../Reference/Decorators.md),
 the decorated variables will not be accessible before calling `.listen()`,
-`.inject()` or `.ready()`.
+`.inject()`, or `.ready()`.
 
 In case you rely on a variable injected by a preceding plugin and want to pass
 that in the `options` argument of `register`, you can do so by using a function

docs/Guides/Serverless.md

@@ -280,8 +280,8 @@ const { onRequest } = require("firebase-functions/v2/https")
 ### Creation of Fastify instance
 
 Create the Fastify instance and encapsulate the returned application instance
-in a function which will register routes, await the server's processing of
-plugins, hooks and other settings. As follows:
+in a function that will register routes, await the server's processing of
+plugins, hooks, and other settings. As follows:
 
 ```js
 const fastify = require("fastify")({
@@ -299,7 +299,7 @@ const fastifyApp = async (request, reply) => {
 
 Firebase Function's HTTP layer already parses the request
 and makes a JSON payload available. It also provides access
-to the raw body, unparsed, which is useful in order to calculate
+to the raw body, unparsed, which is useful for calculating
 request signatures to validate HTTP webhooks.
 
 Add as follows to the `registerRoutes()` function:
@@ -384,7 +384,7 @@ familiar with gcloud or just follow their
 
 ### Adjust Fastify server
 
-In order for Fastify to properly listen for requests within the container, be
+For Fastify to properly listen for requests within the container, be
 sure to set the correct port and address:
 
 ```js

docs/Guides/Style-Guide.md

@@ -83,7 +83,7 @@ Result:
 
 Make sure you avoid copying other people's work. Keep it as original as
 possible. You can learn from what they have done and reference where it is from
-if you used a particular quote from their work.
+if you use a particular quote from their work.
 
 
 ## Word Choice
@@ -217,7 +217,7 @@ Styles](https://medium.com/better-programming/string-case-styles-camel-pascal-sn
 
 ### Hyperlinks
 
-Hyperlinks should have a clear title of what it references. Here is how your
+Hyperlinks should have a clear title of what they reference. Here is how your
 hyperlink should look:
 
 ```MD

docs/Guides/Write-Plugin.md

@@ -14,7 +14,7 @@ suggestion"](https://github.com/fastify/fastify/issues?q=is%3Aissue+is%3Aopen+la
 in our issue tracker!*
 
 ## Code
-Fastify uses different techniques to optimize its code, many of them are
+Fastify uses different techniques to optimize its code, many of which are
 documented in our Guides. We highly recommend you read [the hitchhiker's guide
 to plugins](./Plugins-Guide.md) to discover all the APIs you can use to build
 your plugin and learn how to use them.
@@ -53,8 +53,7 @@ Always put an example file in your repository. Examples are very helpful for
 users and give a very fast way to test your plugin. Your users will be grateful.
 
 ## Test
-It is extremely important that a plugin is thoroughly tested to verify that is
-working properly.
+A plugin **must** be thoroughly tested to verify that is working properly.
 
 A plugin without tests will not be accepted to the ecosystem list. A lack of
 tests does not inspire trust nor guarantee that the code will continue to work