fastify 4.0.0 → 4.0.3

package/SECURITY.md

@@ -1,36 +1,37 @@
 # Security Policy
 
-This document describes the management of vulnerabilities for the
-Fastify project and its official plugins.
+This document describes the management of vulnerabilities for the Fastify
+project and its official plugins.
 
 ## Reporting vulnerabilities
 
-Individuals who find potential vulnerabilities in Fastify are invited
-to complete a vulnerability report via the dedicated HackerOne page:
+Individuals who find potential vulnerabilities in Fastify are invited to
+complete a vulnerability report via the dedicated HackerOne page:
 [https://hackerone.com/fastify](https://hackerone.com/fastify).
 
 ### Strict measures when reporting vulnerabilities
 
 It is of the utmost importance that you read carefully and follow these
-guidelines to ensure the ecosystem as a whole isn't disrupted due to
-improperly reported vulnerabilities:
+guidelines to ensure the ecosystem as a whole isn't disrupted due to improperly
+reported vulnerabilities:
 
 * Avoid creating new "informative" reports on HackerOne. Only create new
-  HackerOne reports on a vulnerability if you are absolutely sure this
-  should be tagged as an actual vulnerability. Third-party vendors and
-  individuals are tracking any new vulnerabilities reported in HackerOne
-  and will flag them as such for their customers (think about snyk, npm audit, ...).
-* HackerOne reports should never be created and triaged by the same person.
-  If you are creating a HackerOne report for a vulnerability that you found,
-  or on behalf of someone else, there should always be a 2nd Security Team
-  member who triages it. If in doubt, invite more Fastify Collaborators to
-  help triage the validity of the report. In any case, the report should
-  follow the same process as outlined below of inviting the maintainers
-  to review and accept the vulnerability.
+  HackerOne reports on a vulnerability if you are absolutely sure this should be
+  tagged as an actual vulnerability. Third-party vendors and individuals are
+  tracking any new vulnerabilities reported in HackerOne and will flag them as
+  such for their customers (think about snyk, npm audit, ...).
+* HackerOne reports should never be created and triaged by the same person. If
+  you are creating a HackerOne report for a vulnerability that you found, or on
+  behalf of someone else, there should always be a 2nd Security Team member who
+  triages it. If in doubt, invite more Fastify Collaborators to help triage the
+  validity of the report. In any case, the report should follow the same process
+  as outlined below of inviting the maintainers to review and accept the
+  vulnerability.
 
 ### Vulnerabilities found outside this process
 
-⚠ The Fastify project does not support any reporting outside the HackerOne process.
+⚠ The Fastify project does not support any reporting outside the HackerOne
+process.
 
 ## Handling vulnerability reports
 
@@ -40,37 +41,40 @@ When a potential vulnerability is reported, the following actions are taken:
 
 **Delay:** 4 business days
 
-Within 4 business days, a member of the security team provides a first answer to the
-individual who submitted the potential vulnerability. The possible responses
+Within 4 business days, a member of the security team provides a first answer to
+the individual who submitted the potential vulnerability. The possible responses
 can be:
 
 * Acceptance: what was reported is considered as a new vulnerability
 * Rejection: what was reported is not considered as a new vulnerability
-* Need more information: the security team needs more information in order to evaluate what was reported.
+* Need more information: the security team needs more information in order to
+  evaluate what was reported.
 
 Triaging should include updating issue fields:
 * Asset - set/create the module affected by the report
 * Severity - TBD, currently left empty
 
-Reference: [HackerOne: Submitting Reports](https://docs.hackerone.com/hackers/submitting-reports.html)
+Reference: [HackerOne: Submitting
+Reports](https://docs.hackerone.com/hackers/submitting-reports.html)
 
 ### Correction follow-up
 
 **Delay:** 90 days
 
-When a vulnerability is confirmed, a member of the security team volunteers to follow
-up on this report.
+When a vulnerability is confirmed, a member of the security team volunteers to
+follow up on this report.
 
-With the help of the individual who reported the vulnerability, they contact
-the maintainers of the vulnerable package to make them aware of the
-vulnerability. The maintainers can be invited as participants to the reported issue.
+With the help of the individual who reported the vulnerability, they contact the
+maintainers of the vulnerable package to make them aware of the vulnerability.
+The maintainers can be invited as participants to the reported issue.
 
-With the package maintainer, they define a release date for the publication
-of the vulnerability. Ideally, this release date should not happen before
-the package has been patched.
+With the package maintainer, they define a release date for the publication of
+the vulnerability. Ideally, this release date should not happen before the
+package has been patched.
 
 The report's vulnerable versions upper limit should be set to:
-* `*` if there is no fixed version available by the time of publishing the report.
+* `*` if there is no fixed version available by the time of publishing the
+  report.
 * the last vulnerable version. For example: `<=1.2.3` if a fix exists in `1.2.4`
 
 ### Publication
@@ -79,34 +83,41 @@ The report's vulnerable versions upper limit should be set to:
 
 Within 90 days after the triage date, the vulnerability must be made public.
 
-**Severity**: Vulnerability severity is assessed using [CVSS v.3](https://www.first.org/cvss/user-guide).
-More information can be found on [HackerOne documentation](https://docs.hackerone.com/hackers/severity.html)
+**Severity**: Vulnerability severity is assessed using [CVSS
+v.3](https://www.first.org/cvss/user-guide). More information can be found on
+[HackerOne documentation](https://docs.hackerone.com/hackers/severity.html)
 
 If the package maintainer is actively developing a patch, an additional delay
 can be added with the approval of the security team and the individual who
-reported the vulnerability. 
+reported the vulnerability.
 
 At this point, a CVE should be requested through the HackerOne platform through
 the UI, which should include the Report ID and a summary.
 
 Within HackerOne, this is handled through a "public disclosure request".
 
-Reference: [HackerOne: Disclosure](https://docs.hackerone.com/hackers/disclosure.html)
+Reference: [HackerOne:
+Disclosure](https://docs.hackerone.com/hackers/disclosure.html)
 
 ## The Fastify Security team
 
-The core team is responsible for the management of HackerOne program and this policy and process.
+The core team is responsible for the management of HackerOne program and this
+policy and process.
 
-Members of this team are expected to keep all information that they have privileged access to by being
-on the team completely private to the team. This includes agreeing to not notify anyone outside the
-team of issues that have not yet been disclosed publicly, including the existence of issues,
-expectations of upcoming releases, and patching of any issues other than in the process of their work
-as a member of the Fastify Core team.
+Members of this team are expected to keep all information that they have
+privileged access to by being on the team completely private to the team. This
+includes agreeing to not notify anyone outside the team of issues that have not
+yet been disclosed publicly, including the existence of issues, expectations of
+upcoming releases, and patching of any issues other than in the process of their
+work as a member of the Fastify Core team.
 
 ### Members
 
-* [__Matteo Collina__](https://github.com/mcollina), <https://twitter.com/matteocollina>, <https://www.npmjs.com/~matteo.collina>
-* [__Tomas Della Vedova__](https://github.com/delvedor), <https://twitter.com/delvedor>, <https://www.npmjs.com/~delvedor>
+* [__Matteo Collina__](https://github.com/mcollina),
+  <https://twitter.com/matteocollina>, <https://www.npmjs.com/~matteo.collina>
+* [__Tomas Della Vedova__](https://github.com/delvedor),
+  <https://twitter.com/delvedor>, <https://www.npmjs.com/~delvedor>
 * [__Vincent Le Goff__](https://github.com/zekth)
 * [__KaKa Ng__](https://github.com/climba03003)
-* [__James Sumners__](https://github.com/jsumners), <https://twitter.com/jsumners79>, <https://www.npmjs.com/~jsumners>
+* [__James Sumners__](https://github.com/jsumners),
+  <https://twitter.com/jsumners79>, <https://www.npmjs.com/~jsumners>

package/build/build-error-serializer.js

@@ -1,10 +1,11 @@
+/* istanbul ignore file */
 'use strict'
 
 const FJS = require('fast-json-stringify')
 const path = require('path')
 const fs = require('fs')
 
-const debugCompiled = FJS({
+const code = FJS({
   type: 'object',
   properties: {
     statusCode: { type: 'number' },
@@ -12,16 +13,20 @@ const debugCompiled = FJS({
     error: { type: 'string' },
     message: { type: 'string' }
   }
-}, { debugMode: true })
+}, { mode: 'standalone' })
 
 const file = path.join(__dirname, '..', 'lib', 'error-serializer.js')
-const rawString = debugCompiled.toString()
 
 const moduleCode = `// This file is autogenerated by build/build-error-serializer.js, do not edit
 /* istanbul ignore file */
-module.exports = $main
-${rawString.slice(5)}
+${code}
 `
 
-fs.writeFileSync(file, moduleCode)
-console.log(`Saved ${file} file successfully`)
+if (require.main === module) {
+  fs.writeFileSync(file, moduleCode)
+  console.log(`Saved ${file} file successfully`)
+} else {
+  module.exports = {
+    code: moduleCode
+  }
+}

package/docs/Guides/Benchmarking.md

@@ -53,6 +53,8 @@ npm run bench
 
 ### Run different examples
 
+<!-- markdownlint-disable -->
 ```sh
 branchcmp --rounds 2 -s "node ./node_modules/concurrently -k -s first \"node ./examples/asyncawait.js\" \"node ./node_modules/autocannon -c 100 -d 5 -p 10 localhost:3000/\""
 ```
+<!-- markdownlint-enable -->

package/docs/Guides/Delay-Accepting-Requests.md

@@ -5,15 +5,16 @@
 ## Introduction
 
 Fastify provides several [hooks](../Reference/Hooks.md) useful for a variety of
-situations. One of them is the [`onReady`](../Reference/Hooks.md#onready) hook, which is
-useful for executing tasks *right before* the server starts accepting new
-requests. There isn't, though, a direct mechanism to handle scenarios in which
-you'd like the server to start accepting **specific** requests and denying all
-others, at least up to some point.
-
-Say, for instance, your server needs to authenticate with an OAuth provider
-to start serving requests. To do that it'd need to engage in the
-[OAuth Authorization Code Flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow),
+situations. One of them is the [`onReady`](../Reference/Hooks.md#onready) hook,
+which is useful for executing tasks *right before* the server starts accepting
+new requests. There isn't, though, a direct mechanism to handle scenarios in
+which you'd like the server to start accepting **specific** requests and denying
+all others, at least up to some point.
+
+Say, for instance, your server needs to authenticate with an OAuth provider to
+start serving requests. To do that it'd need to engage in the [OAuth
+Authorization Code
+Flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow),
 which would require it to listen to two requests from the authentication
 provider:
 
@@ -31,14 +32,13 @@ rolling asap!
 
 ### Overview
 
-The proposed solution is one of many possible ways of dealing with this
-scenario and many similar to it. It relies solely on Fastify, so no
-fancy infrastructure tricks or third-party libraries will be necessary.
+The proposed solution is one of many possible ways of dealing with this scenario
+and many similar to it. It relies solely on Fastify, so no fancy infrastructure
+tricks or third-party libraries will be necessary.
 
-To simplify things we won't be dealing with a precise OAuth flow but,
-instead, simulate a scenario in which some key is needed to serve
-a request and that key can only be retrieved in runtime by authenticating with
-an external provider.
+To simplify things we won't be dealing with a precise OAuth flow but, instead,
+simulate a scenario in which some key is needed to serve a request and that key
+can only be retrieved in runtime by authenticating with an external provider.
 
 The main goal here is to deny requests that would otherwise fail **as early as
 possible** and with some **meaningful context**. That's both useful for the
@@ -97,7 +97,7 @@ server.get('/v1*', async function (request, reply) {
       error,
       message: 'Failed at fetching sensitive data from provider',
     })
-    
+
     reply.statusCode = 500
     return { customer: null, error: true }
   }
@@ -122,13 +122,13 @@ server.listen({ port: '1234' }, () => {
 
 Our code is simply setting up a Fastify server with a few routes:
 
-- a `/ping` route that specifies whether the service is ready or
-not to serve requests by checking if the `magicKey` has been set up
-- a `/webhook` endpoint for our provider to reach back to us when
-they're ready to share the `magicKey`. The `magicKey` is, then, saved into the
-previously set decorator on the `fastify` object
-- a catchall `/v1*` route to simulate what would have been
-customer-initiated requests. These requests rely on us having a valid `magicKey`
+- a `/ping` route that specifies whether the service is ready or not to serve
+requests by checking if the `magicKey` has been set up
+- a `/webhook` endpoint for our provider to reach back to us when they're ready
+to share the `magicKey`. The `magicKey` is, then, saved into the previously set
+decorator on the `fastify` object
+- a catchall `/v1*` route to simulate what would have been customer-initiated
+requests. These requests rely on us having a valid `magicKey`
 
 The `provider.js` file, simulating actions of an external provider, is as
 follows:
@@ -166,11 +166,11 @@ exports.fetchSensitiveData = async (key) => {
   // Simulate processing delay
   await delay(700)
   const data = { sensitive: true }
-  
+
   if (key === MAGIC_KEY) {
     return data
   }
-  
+
   throw new Error('Invalid key')
 }
 ```
@@ -184,16 +184,16 @@ our `magicKey` set up. Until we receive the webhook request from our external
 provider (in this example we're simulating a 5 second delay) all our requests
 under the `/v1*` path (customer requests) will fail. Worse than that: they'll
 fail after we've reached out to our provider with an invalid key and got an
-error from them. That wasted time and resources for us and our
-customers. Depending on the kind of application we're running and on the request
-rate we're expecting this delay is not acceptable or, at least, very annoying.
+error from them. That wasted time and resources for us and our customers.
+Depending on the kind of application we're running and on the request rate we're
+expecting this delay is not acceptable or, at least, very annoying.
 
 Of course, that could be simply mitigated by checking whether or not the
 `magicKey` has been set up before hitting the provider in the `/v1*` handler.
 Sure, but that would lead to bloat in the code. And imagine we have dozens of
-different routes, with different controllers, that require that key. Should
-we repeatedly add that check to all of them? That's error-prone and there are
-more elegant solutions.
+different routes, with different controllers, that require that key. Should we
+repeatedly add that check to all of them? That's error-prone and there are more
+elegant solutions.
 
 What we'll do to improve this setup overall is create a
 [`Plugin`](../Reference/Plugins.md) that'll be solely responsible for making
@@ -280,11 +280,11 @@ exports.fetchSensitiveData = async (key) => {
   // Simulate processing delay
   await delay(700)
   const data = { sensitive: true }
-  
+
   if (key === MAGIC_KEY) {
     return data
   }
-  
+
   throw new Error('Invalid key')
 }
 ```
@@ -381,9 +381,9 @@ There is a very specific change on the previously existing files that is worth
 mentioning: Beforehand we were using the `server.listen` callback to start the
 authentication process with the external provider and we were decorating the
 `server` object right before initializing the server. That was bloating our
-server initialization setup with unnecessary code and didn't have much to
-do with starting the Fastify server. It was a business logic that didn't have
-its specific place in the code base.
+server initialization setup with unnecessary code and didn't have much to do
+with starting the Fastify server. It was a business logic that didn't have its
+specific place in the code base.
 
 Now we've implemented the `delayIncomingRequests` plugin in the
 `delay-incoming-requests.js` file. That's, in truth, a module split into two
@@ -399,11 +399,11 @@ asap and store the `magicKey` somewhere available to all our handlers.
   fastify.server.on('listening', doMagic)
 ```
 
-As soon as the server starts listening (very similar behavior to adding a
-piece of code to the `server.listen`'s callback function) a `listening` event
-is emitted (for more info refer to https://nodejs.org/api/net.html#event-listening).
-We use that to reach out to our provider as soon as possible, with the `doMagic`
-function.
+As soon as the server starts listening (very similar behavior to adding a piece
+of code to the `server.listen`'s callback function) a `listening` event is
+emitted (for more info refer to
+https://nodejs.org/api/net.html#event-listening). We use that to reach out to
+our provider as soon as possible, with the `doMagic` function.
 
 ```js
   fastify.decorate('magicKey', null)
@@ -414,10 +414,10 @@ a placeholder, waiting for the valid value to be retrieved.
 
 ##### delay
 
-`delay` is not a plugin itself. It's actually a plugin *factory*. It expects
-a Fastify plugin with `routes` and exports the actual plugin that'll handle
-enveloping those routes with an `onRequest` hook that will make sure no
-requests are handled until we're ready for them.
+`delay` is not a plugin itself. It's actually a plugin *factory*. It expects a
+Fastify plugin with `routes` and exports the actual plugin that'll handle
+enveloping those routes with an `onRequest` hook that will make sure no requests
+are handled until we're ready for them.
 
 ```js
 const delay = (routes) =>
@@ -441,33 +441,34 @@ const delay = (routes) =>
   }
 ```
 
-Instead of updating every single controller that might use the
-`magicKey`, we simply make sure that no route that's related to customer requests
-will be served until we have everything ready. And there's more: we fail
-**FAST** and 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!
+Instead of updating every single controller that might use the `magicKey`, we
+simply make sure that no route that's related to customer requests will be
+served until we have everything ready. And there's more: we fail **FAST** and
+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!
 
 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
-that specific scope and not to the scope that called it (in our case, the
-main `server` object defined in `index.js`). `fastify-plugin` sets the
-`skip-override` hidden property, which has a practical effect of making
-whatever changes we make to our `fastify` object available to the upper scope.
-That's also why we used it with the `customerRoutes` plugin: we wanted those
-routes to be available to its calling scope, the `delay` plugin. For more info
-on that subject refer to [Plugins](../Reference/Plugins.md#handle-the-scope).
-
-Let's see how that behaves in action. If we fired our server up with
-`node index.js` and made a few requests to test things out. These were the logs
-we'd see (some bloat was removed to ease things up):
-
-```
+that specific scope and not to the scope that called it (in our case, the main
+`server` object defined in `index.js`). `fastify-plugin` sets the
+`skip-override` hidden property, which has a practical effect of making whatever
+changes we make to our `fastify` object available to the upper scope. That's
+also why we used it with the `customerRoutes` plugin: we wanted those routes to
+be available to its calling scope, the `delay` plugin. For more info on that
+subject refer to [Plugins](../Reference/Plugins.md#handle-the-scope).
+
+Let's see how that behaves in action. If we fired our server up with `node
+index.js` and made a few requests to test things out. These were the logs we'd
+see (some bloat was removed to ease things up):
+
+<!-- markdownlint-disable -->
+```sh
 {"time":1650063793316,"msg":"Doing magic!"}
 {"time":1650063793316,"msg":"Server listening at http://127.0.0.1:1234"}
 {"time":1650063795030,"reqId":"req-1","req":{"method":"GET","url":"/v1","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51928},"msg":"incoming request"}
@@ -480,10 +481,11 @@ we'd see (some bloat was removed to ease things up):
 {"time":1650063799858,"reqId":"req-4","req":{"method":"GET","url":"/v1","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51934},"msg":"incoming request"}
 {"time":1650063800561,"reqId":"req-4","res":{"statusCode":200},"responseTime":702.4662979990244,"msg":"request completed"}
 ```
+<!-- markdownlint-enable -->
 
 Let's focus on a few parts:
 
-```
+```sh
 {"time":1650063793316,"msg":"Doing magic!"}
 {"time":1650063793316,"msg":"Server listening at http://127.0.0.1:1234"}
 ```
@@ -494,18 +496,20 @@ couldn't do that before the server was ready to receive connections).
 
 While the server is still not ready, a few requests are attempted:
 
-```
+<!-- markdownlint-disable -->
+```sh
 {"time":1650063795030,"reqId":"req-1","req":{"method":"GET","url":"/v1","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51928},"msg":"incoming request"}
 {"time":1650063795033,"reqId":"req-1","res":{"statusCode":503},"responseTime":2.5721680000424385,"msg":"request completed"}
 {"time":1650063796248,"reqId":"req-2","req":{"method":"GET","url":"/ping","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51930},"msg":"incoming request"}
 {"time":1650063796248,"reqId":"req-2","res":{"statusCode":200},"responseTime":0.4802369996905327,"msg":"request completed"}
 ```
+<!-- markdownlint-enable -->
 
 The first one (`req-1`) was a `GET /v1`, that failed (**FAST** - `responseTime`
 is in `ms`) with our `503` status code and the meaningful information in the
 response. Below is the response for that request:
 
-```
+```sh
 HTTP/1.1 503 Service Unavailable
 Connection: keep-alive
 Content-Length: 31
@@ -524,12 +528,12 @@ Then we attempt 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
 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:
+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:
 
-```
+```sh
 HTTP/1.1 200 OK
 Connection: keep-alive
 Content-Length: 29
@@ -545,26 +549,30 @@ Keep-Alive: timeout=5
 
 After that there were more interesting log messages:
 
-```
+<!-- markdownlint-disable -->
+```sh
 {"time":1650063798377,"reqId":"req-3","req":{"method":"POST","url":"/webhook","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51932},"msg":"incoming request"}
 {"time":1650063798379,"reqId":"req-3","msg":"Ready for customer requests!"}
 {"time":1650063798379,"reqId":"req-3","res":{"statusCode":200},"responseTime":1.3567829988896847,"msg":"request completed"}
 ```
+<!-- markdownlint-enable -->
 
 This time it was our simulated external provider hitting us to let us know
 authentication had gone well and telling us what our `magicKey` was. We saved
 that into our `magicKey` decorator and celebrated with a log message saying we
 were now ready for customers to hit us!
 
-```
+<!-- markdownlint-disable -->
+```sh
 {"time":1650063799858,"reqId":"req-4","req":{"method":"GET","url":"/v1","hostname":"localhost:1234","remoteAddress":"127.0.0.1","remotePort":51934},"msg":"incoming request"}
 {"time":1650063800561,"reqId":"req-4","res":{"statusCode":200},"responseTime":702.4662979990244,"msg":"request completed"}
 ```
+<!-- markdownlint-enable -->
 
 Finally, a final `GET /v1` request was made and, this time, it succeeded. Its
 response was the following:
 
-```
+```sh
 HTTP/1.1 200 OK
 Connection: keep-alive
 Content-Length: 31
@@ -580,18 +588,18 @@ Keep-Alive: timeout=5
 
 ## Conclusion
 
-Specifics of the implementation will vary
-from one problem to another, but the main goal of this guide was to show a very
-specific use case of an issue that could be solved within Fastify's ecosystem.
+Specifics of the implementation will vary from one problem to another, but the
+main goal of this guide was to show a very specific use case of an issue that
+could be solved within Fastify's ecosystem.
 
 This guide is a tutorial on the use of plugins, decorators, and hooks to solve
 the problem of delaying serving specific requests on our application. It's not
 production-ready, as it keeps local state (the `magicKey`) and it's not
-horizontally scalable (we don't want to flood our provider, right?). One way
-of improving it would be storing the `magicKey` somewhere else (perhaps a
-cache database?).
+horizontally scalable (we don't want to flood our provider, right?). One way of
+improving it would be storing the `magicKey` somewhere else (perhaps a cache
+database?).
 
 The keywords here were [Decorators](../Reference/Decorators.md),
-[Hooks](../Reference/Hooks.md), and [Plugins](../Reference/Plugins.md). Combining
-what Fastify has to offer can lead to very ingenious and creative solutions to a
-wide variety of problems. Let's be creative! :)
+[Hooks](../Reference/Hooks.md), and [Plugins](../Reference/Plugins.md).
+Combining what Fastify has to offer can lead to very ingenious and creative
+solutions to a wide variety of problems. Let's be creative! :)