diff --git a/README.md b/README.md
index 2a1c4c1556..f2f2a29b6e 100644
--- a/README.md
+++ b/README.md
@@ -1,31 +1,66 @@
-# Source Repository for graphql.org
+# Source Repository for GraphQL.org
 
 This repository contains the source code for the [GraphQL website](https://graphql.org).
 
-> You can find more discussions on the [#website channel on the GraphQL Slack](https://graphql.slack.com/messages/website/). [Get your invite here!](https://graphql-slack.herokuapp.com/)
+You can find more discussions on the #website channel on [the GraphQL Discord](https://discord.graphql.org).
 
-A brief overview: **GraphQL** is a query language for APIs and a runtime for fulfilling those queries with your existing data. It provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need, and enables powerful developer tools. The [specification](https://spec.graphql.org/) is open source and governed by the [GraphQL Foundation](https://foundation.graphql.org/).
+## Table of Contents
+
+- [Overview](#overview)
+- [Documentation](#documentation)
+- [Deployment](#deployment)
+- [How to Contribute](#how-to-contribute)
+- [CLA Process](#cla-process)
+- [Financial Support](#financial-support)
+
+## Overview
+
+**GraphQL** is a query language for APIs and a runtime for fulfilling those queries with your existing data. It provides:
+
+- a complete and understandable description of the data in your API,
+- support for powerful developer tooling, and
+- precise querying, which offers several benefits:
+  - clients request only the data they need, improving efficiency;
+  - new fields and features can be added without impacting existing clients; and
+  - field-level usage can be tracked and monitored for insights and optimization.
+
+The [GraphQL Specification](https://spec.graphql.org/) is open source and governed by the [GraphQL Foundation](https://foundation.graphql.org/).
 
 ## Documentation
 
-- [Site](https://graphql.org/)
-- [Reference documentation](https://graphql.org/learn/)
-- [Language support, tools, and services](https://graphql.org/code/)
+- [GraphQL Website](https://graphql.org/)
+- [Reference Documentation](https://graphql.org/learn/)
+- [Language Support, Tools, and Services](https://graphql.org/code/)
 - [Frequently Asked Questions (FAQ)](https://graphql.org/faq/)
-- [Community resources](https://graphql.org/community/)
+- [Community Resources](https://graphql.org/community/)
 
 ## Deployment
 
-The site is deployed via Vercel on merges to the `source` branch.
+The website is deployed via [Vercel](https://vercel.com) on merges to the `source` branch. To preview changes locally, follow these steps:
+
+1. Clone the repository:  
+   `git clone https://github.com/graphql/graphql.github.io.git`  
+   `cd graphql.github.io`
+2. Install dependencies:  
+   `npm install`
+3. Run the site locally:  
+   `npm run dev`
+
+## How to Contribute
+
+We welcome contributions! 🎉 Please refer to our [contributing guide](./CONTRIBUTING.md) for detailed instructions on how to make changes to the GraphQL website.
+
+### CLA Process
 
-## How to contribute
+Before contributing, all participants must sign the free [GraphQL Specification Membership Agreement](https://preview-spec-membership.graphql.org). You only need to do this once, and it can be signed by:
 
-Check out our [contributing guide](./CONTRIBUTING.md) for detailed instructions on how to make changes to the GraphQL website 🎉.
+- [Individual contributors](http://individual-spec-membership.graphql.org/)
+- [Employers](http://corporate-spec-membership.graphql.org/)
 
-This repository is managed by EasyCLA. Project participants must sign the free [GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org) before making a contribution. You only need to do this one time, and it can be signed by [individual contributors](http://individual-spec-membership.graphql.org/) or their [employers](http://corporate-spec-membership.graphql.org/).
+To initiate the signature process, please open a PR against this repository. The EasyCLA bot will block the merge if the membership agreement has not been signed.
 
-To initiate the signature process please open a PR against this repo. The EasyCLA bot will block the merge if we still need a membership agreement from you.
+For more information on the CLA, check out the [detailed instructions here](https://github.com/graphql/graphql-wg/tree/main/membership). If you encounter any issues, please contact us at [operations@graphql.org](mailto:operations@graphql.org).
 
-You can find [detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership). If you have issues, please email operations@graphql.org.
+## Join the Foundation!
 
-If your company benefits from GraphQL and you would like to provide essential financial support for the systems and people that power our community, please also consider membership in the [GraphQL Foundation](https://foundation.graphql.org/join).
+If your company benefits from GraphQL and you would like to provide essential financial support for the systems and people that power our community, please consider becoming a member of the [GraphQL Foundation](https://foundation.graphql.org/join).
diff --git a/public/.well-known/atproto-did b/public/.well-known/atproto-did
new file mode 100644
index 0000000000..acf7f09a00
--- /dev/null
+++ b/public/.well-known/atproto-did
@@ -0,0 +1 @@
+did:plc:a65ga6opvhd2h453vwscrvil
diff --git a/public/images/next-image-export-optimizer-hashes.json b/public/images/next-image-export-optimizer-hashes.json
index 7d514378af..d4d8015a93 100644
--- a/public/images/next-image-export-optimizer-hashes.json
+++ b/public/images/next-image-export-optimizer-hashes.json
@@ -25,6 +25,7 @@
     "/8_53229629805_o.290e35be.jpg": "NfsXTg4KKkt1csv79IiZ3FyU3-CW1WTkp4883NgZam4=",
     "/9.4a558c85.jpg": "-iUSFWjVs4vunEea7FxDeNMOOvUs4VOEpScXJAwi0DA=",
     "/annual-report-1.5ebe2b34.png": "HmbFFbaUL79rvnCKQ-2oRSLETM2FFh5v5dZxwWquuVM=",
+    "/audience.f60c1c99.jpg": "pqx3E31xAO87mNEBlZKqCTX+LRiPlOuQThWQZf08A4A=",
     "/banner.10d4d66b.jpg": "9UJqBQ9RQu2sxDdJ5uaQr3crx2ZXrlOKMAmY82R8ZBA=",
     "/business_layer.68bf746f.png": "DwCtOs-q1Y-DgBxEj6NqyVaOAiq5zCB8xPF-rZ5Qe1U=",
     "/coursera.968d6897.png": "FmQxkHPToU9hZQFvKVSRa6+-5xppLy6lJJhqCEIiCzk=",
@@ -133,10 +134,13 @@
     "/graphqlconf-202395_53229430163_o.83d6ce30.jpg": "wGPGuLNhdPy1AKSdem7dB2U3hCnLNt0m7A697OKpMLA=",
     "/graphqlconf-202396_53229628185_o.e02e8158.jpg": "CwcPIFPl3qMN77xrq3PNo3IDu2xdE5t-XAmqMN7vvrA=",
     "/graphqlconf-2023graphqlconf-2023_53228255062_o.29b776c3.jpg": "iXr9Z8xwKZhM1pUZPRRTFEHbvwYlw81k6ZIqW5zh3x4=",
+    "/hero1.2c973c2e.jpg": "jY1RePeWthuOOa5c59Yl4TQD4J731poNxeaqzKDFmfg=",
+    "/hero2.fa425ea9.jpg": "siZR-Q3HPEB5l2gU0DAbheWVVUOCsrOuOv-Ch0xCR7M=",
     "/idit.feda6f62.jpg": "9oybNQ8aiuV++33v8KDL8ZgIL0H2T5UF3EjnhsksM5g=",
     "/intuit.04140a09.png": "m84fUDz2YQxlNNMmbthcNfYr3bWhp23zEPxvP5ruo9Q=",
     "/layers-2x.9859cd12.png": "3D8k4Go-oWvQTcmIDFOwHTfm1eagZIqjwar3vFcoZY8=",
     "/layers.ef6db872.png": "fbR0XaZWR0olI2fUKeOWruBZ6HxRDSEYGXCzktrW4XA=",
+    "/lee.dfa51298.png": "rG86vKMradTmaq1FH-F2-zwDzRkcw-qXK18Slp34VPs=",
     "/leebyron.4adb0a93.jpg": "poBi-hIdozz-Mn2PIKun7ZpX9q200f7m-5SkUt1XU-0=",
     "/marcandre.b8692933.jpg": "mUbreFySTVojHKZTl0VKcMQ9gHdSVCL47mSBnUYITBI=",
     "/marker-icon.d577052a.png": "L15ETF3vWj9pjeLgXar+ibZOYNJYXoQal5lJmpTWTbA=",
@@ -144,8 +148,10 @@
     "/pinterest.36b58187.png": "TlwGD0W-rRqoDgDND5x+cQrzz09xU+dmW6oP8+qSBug=",
     "/playground-transition-banner.2458871d.png": "ffm4o7utOWkmwaWC2KVVHPOz9zsaD6fG2P269pHT8uQ=",
     "/rest-api-people.c2b56e20.png": "KDbPJA1rAhVT43LeGLckdesx+bISV+6g0q9fJQNl5Tg=",
-    "/sf-city-view.d5d36dff.jpeg": "a-QVXW74jpiDFhmUOc9hZY10pGvmpSLSdM+u0EcuRac=",
     "/shopify.2cb330ea.png": "LRiC9+uEG-gHl-XYi4qrSXMAlpFglZLNZj1kBGF-Cag=",
+    "/speaker.674c5b86.jpg": "ISlnB9At3nuMk70rfRuMAu+k9aEhUNSwp7XgFMx5Bls=",
+    "/unconf.651492c3.jpg": "mlpvU8glWqqsRn2n3-pgwRI+Jnk3sT7VQjsCL01e30c=",
     "/uri.387cb001.jpg": "kSx4huEjQidwIg6bF8UEWLiPACDl0nQ0aqxA2R2LIe0=",
-    "/whiteboard.60eac8e3.jpg": "NodBqUaO+IanhuPaP9o5jCIe+gSrwyZ9TZ3QUdlWbBg="
+    "/whiteboard.60eac8e3.jpg": "NodBqUaO+IanhuPaP9o5jCIe+gSrwyZ9TZ3QUdlWbBg=",
+    "/workshop.e02e3501.jpg": "D9ON1z6-vKcjxv50gOH+5XS9HTEWUpc4UgIPW5OXHxE="
 }
\ No newline at end of file
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-10.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-10.WEBP
new file mode 100644
index 0000000000..66eb869864
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-128.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-128.WEBP
new file mode 100644
index 0000000000..7aeb554b19
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-16.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-16.WEBP
new file mode 100644
index 0000000000..7c4002b78c
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-256.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-256.WEBP
new file mode 100644
index 0000000000..04fcbd191f
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-32.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-32.WEBP
new file mode 100644
index 0000000000..cf8bc5216f
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-384.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-384.WEBP
new file mode 100644
index 0000000000..fb51ae7534
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-48.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-48.WEBP
new file mode 100644
index 0000000000..ffead8e573
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-64.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-64.WEBP
new file mode 100644
index 0000000000..dc80da647a
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-640.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-640.WEBP
new file mode 100644
index 0000000000..14aca601e6
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-750.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-750.WEBP
new file mode 100644
index 0000000000..6ccd850c0d
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-828.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-828.WEBP
new file mode 100644
index 0000000000..70e9adefee
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/audience.f60c1c99-opt-96.WEBP b/public/nextImageExportOptimizer/audience.f60c1c99-opt-96.WEBP
new file mode 100644
index 0000000000..17d7d3b34e
Binary files /dev/null and b/public/nextImageExportOptimizer/audience.f60c1c99-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-10.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-10.WEBP
new file mode 100644
index 0000000000..1d966f91fe
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1080.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1080.WEBP
new file mode 100644
index 0000000000..d634eeee86
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1080.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1200.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1200.WEBP
new file mode 100644
index 0000000000..159594a772
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1200.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-128.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-128.WEBP
new file mode 100644
index 0000000000..a9cb08f01f
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-16.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-16.WEBP
new file mode 100644
index 0000000000..dc4f66b4d5
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1920.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1920.WEBP
new file mode 100644
index 0000000000..d8f646efb6
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-1920.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-2048.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-2048.WEBP
new file mode 100644
index 0000000000..065a3fc7f1
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-2048.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-256.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-256.WEBP
new file mode 100644
index 0000000000..6d1c74a2bf
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-32.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-32.WEBP
new file mode 100644
index 0000000000..d8e221c99a
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-384.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-384.WEBP
new file mode 100644
index 0000000000..5024ce7f5f
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-3840.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-3840.WEBP
new file mode 100644
index 0000000000..d27590846a
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-3840.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-48.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-48.WEBP
new file mode 100644
index 0000000000..2fdb383072
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-64.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-64.WEBP
new file mode 100644
index 0000000000..6b9248726e
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-640.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-640.WEBP
new file mode 100644
index 0000000000..d995857beb
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-750.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-750.WEBP
new file mode 100644
index 0000000000..df7df107e4
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-828.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-828.WEBP
new file mode 100644
index 0000000000..83fe502a28
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero1.2c973c2e-opt-96.WEBP b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-96.WEBP
new file mode 100644
index 0000000000..2b0bde23a8
Binary files /dev/null and b/public/nextImageExportOptimizer/hero1.2c973c2e-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-10.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-10.WEBP
new file mode 100644
index 0000000000..fc2466255e
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1080.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1080.WEBP
new file mode 100644
index 0000000000..20cc807899
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1080.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1200.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1200.WEBP
new file mode 100644
index 0000000000..0ee60ba536
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1200.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-128.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-128.WEBP
new file mode 100644
index 0000000000..20f161173b
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-16.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-16.WEBP
new file mode 100644
index 0000000000..017783d5e5
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1920.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1920.WEBP
new file mode 100644
index 0000000000..2a706aed00
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-1920.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-2048.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-2048.WEBP
new file mode 100644
index 0000000000..65590fcf18
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-2048.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-256.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-256.WEBP
new file mode 100644
index 0000000000..83abb18c39
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-32.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-32.WEBP
new file mode 100644
index 0000000000..f258e5be5d
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-384.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-384.WEBP
new file mode 100644
index 0000000000..dd260553d3
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-3840.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-3840.WEBP
new file mode 100644
index 0000000000..999f42c469
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-3840.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-48.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-48.WEBP
new file mode 100644
index 0000000000..cac260bdb1
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-64.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-64.WEBP
new file mode 100644
index 0000000000..509a112d28
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-640.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-640.WEBP
new file mode 100644
index 0000000000..c3cfb59403
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-750.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-750.WEBP
new file mode 100644
index 0000000000..7ba79d85a9
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-828.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-828.WEBP
new file mode 100644
index 0000000000..d4a0f27952
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/hero2.fa425ea9-opt-96.WEBP b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-96.WEBP
new file mode 100644
index 0000000000..39db69e817
Binary files /dev/null and b/public/nextImageExportOptimizer/hero2.fa425ea9-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-10.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-10.WEBP
new file mode 100644
index 0000000000..4bebcb89e8
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-1080.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-1080.WEBP
new file mode 100644
index 0000000000..7d8bef55ce
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-1080.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-1200.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-1200.WEBP
new file mode 100644
index 0000000000..752619ef9c
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-1200.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-128.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-128.WEBP
new file mode 100644
index 0000000000..4446587a84
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-16.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-16.WEBP
new file mode 100644
index 0000000000..005741af39
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-1920.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-1920.WEBP
new file mode 100644
index 0000000000..24ea96559a
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-1920.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-256.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-256.WEBP
new file mode 100644
index 0000000000..9293f04074
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-32.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-32.WEBP
new file mode 100644
index 0000000000..79c9545eca
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-384.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-384.WEBP
new file mode 100644
index 0000000000..64eaa0ddde
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-48.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-48.WEBP
new file mode 100644
index 0000000000..78d4f7f023
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-64.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-64.WEBP
new file mode 100644
index 0000000000..78b2772e01
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-640.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-640.WEBP
new file mode 100644
index 0000000000..f96e595ba2
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-750.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-750.WEBP
new file mode 100644
index 0000000000..ce7f258c30
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-828.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-828.WEBP
new file mode 100644
index 0000000000..ff1b5c98ba
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/lee.dfa51298-opt-96.WEBP b/public/nextImageExportOptimizer/lee.dfa51298-opt-96.WEBP
new file mode 100644
index 0000000000..b57ad2f98d
Binary files /dev/null and b/public/nextImageExportOptimizer/lee.dfa51298-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-10.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-10.WEBP
deleted file mode 100644
index 56a00ff74d..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-10.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1080.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1080.WEBP
deleted file mode 100644
index fe2a64716e..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1080.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1200.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1200.WEBP
deleted file mode 100644
index d1d33efabe..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1200.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-128.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-128.WEBP
deleted file mode 100644
index c706f73d9c..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-128.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-16.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-16.WEBP
deleted file mode 100644
index 21d9173f8d..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-16.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1920.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1920.WEBP
deleted file mode 100644
index c5605ff000..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-1920.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-2048.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-2048.WEBP
deleted file mode 100644
index 5dc1cff1fc..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-2048.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-256.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-256.WEBP
deleted file mode 100644
index 33f6038992..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-256.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-32.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-32.WEBP
deleted file mode 100644
index c8e4f4527d..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-32.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-384.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-384.WEBP
deleted file mode 100644
index cbaba7614f..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-384.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-3840.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-3840.WEBP
deleted file mode 100644
index a213d101f8..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-3840.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-48.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-48.WEBP
deleted file mode 100644
index ff4da7550d..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-48.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-64.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-64.WEBP
deleted file mode 100644
index 562e787117..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-64.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-640.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-640.WEBP
deleted file mode 100644
index cce7cd72f4..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-640.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-750.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-750.WEBP
deleted file mode 100644
index e60d63ed85..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-750.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-828.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-828.WEBP
deleted file mode 100644
index 31c95d1091..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-828.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-96.WEBP b/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-96.WEBP
deleted file mode 100644
index cbcdcad841..0000000000
Binary files a/public/nextImageExportOptimizer/sf-city-view.d5d36dff-opt-96.WEBP and /dev/null differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-10.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-10.WEBP
new file mode 100644
index 0000000000..a681afbab8
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-128.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-128.WEBP
new file mode 100644
index 0000000000..a35b3f1bd6
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-16.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-16.WEBP
new file mode 100644
index 0000000000..15ecc64449
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-256.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-256.WEBP
new file mode 100644
index 0000000000..b18e9795a4
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-32.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-32.WEBP
new file mode 100644
index 0000000000..c7c2e8d646
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-384.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-384.WEBP
new file mode 100644
index 0000000000..55328a6d56
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-48.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-48.WEBP
new file mode 100644
index 0000000000..3a6a968572
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-64.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-64.WEBP
new file mode 100644
index 0000000000..4f13c3d354
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-640.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-640.WEBP
new file mode 100644
index 0000000000..0ccce25653
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-750.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-750.WEBP
new file mode 100644
index 0000000000..0dd9c58daf
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-828.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-828.WEBP
new file mode 100644
index 0000000000..2688687ab7
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/speaker.674c5b86-opt-96.WEBP b/public/nextImageExportOptimizer/speaker.674c5b86-opt-96.WEBP
new file mode 100644
index 0000000000..4efb74d4bc
Binary files /dev/null and b/public/nextImageExportOptimizer/speaker.674c5b86-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-10.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-10.WEBP
new file mode 100644
index 0000000000..dfd624a341
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-128.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-128.WEBP
new file mode 100644
index 0000000000..7f0df581f7
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-16.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-16.WEBP
new file mode 100644
index 0000000000..fa24aa9bbd
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-256.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-256.WEBP
new file mode 100644
index 0000000000..d11517fe6e
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-32.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-32.WEBP
new file mode 100644
index 0000000000..c3115845d8
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-384.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-384.WEBP
new file mode 100644
index 0000000000..26483d486c
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-48.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-48.WEBP
new file mode 100644
index 0000000000..dcf74f7b69
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-64.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-64.WEBP
new file mode 100644
index 0000000000..063dec17b4
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-640.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-640.WEBP
new file mode 100644
index 0000000000..07d247a16d
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-750.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-750.WEBP
new file mode 100644
index 0000000000..39d0446cb3
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-828.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-828.WEBP
new file mode 100644
index 0000000000..803bbdebe9
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/unconf.651492c3-opt-96.WEBP b/public/nextImageExportOptimizer/unconf.651492c3-opt-96.WEBP
new file mode 100644
index 0000000000..15ea49d2f5
Binary files /dev/null and b/public/nextImageExportOptimizer/unconf.651492c3-opt-96.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-10.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-10.WEBP
new file mode 100644
index 0000000000..dd81b2644f
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-10.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-128.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-128.WEBP
new file mode 100644
index 0000000000..cfa1e55870
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-128.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-16.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-16.WEBP
new file mode 100644
index 0000000000..c3f58ea182
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-16.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-256.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-256.WEBP
new file mode 100644
index 0000000000..816aff3f06
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-256.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-32.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-32.WEBP
new file mode 100644
index 0000000000..8056c4b27c
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-32.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-384.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-384.WEBP
new file mode 100644
index 0000000000..e749032f87
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-384.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-48.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-48.WEBP
new file mode 100644
index 0000000000..13d3a5c172
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-48.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-64.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-64.WEBP
new file mode 100644
index 0000000000..7888e012f0
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-64.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-640.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-640.WEBP
new file mode 100644
index 0000000000..fa45450037
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-640.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-750.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-750.WEBP
new file mode 100644
index 0000000000..5d33cfac90
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-750.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-828.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-828.WEBP
new file mode 100644
index 0000000000..d7584a37b0
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-828.WEBP differ
diff --git a/public/nextImageExportOptimizer/workshop.e02e3501-opt-96.WEBP b/public/nextImageExportOptimizer/workshop.e02e3501-opt-96.WEBP
new file mode 100644
index 0000000000..c677d502d1
Binary files /dev/null and b/public/nextImageExportOptimizer/workshop.e02e3501-opt-96.WEBP differ
diff --git a/src/app/conf/2024/schedule/[id]/page.tsx b/src/app/conf/2024/schedule/[id]/page.tsx
index 5c8192773a..cb9136d3e6 100644
--- a/src/app/conf/2024/schedule/[id]/page.tsx
+++ b/src/app/conf/2024/schedule/[id]/page.tsx
@@ -68,7 +68,7 @@ const Tag = ({
     <span
       className={clsx(
         "border border-solid border-[#333333] font-semibold text-sm px-3 py-1 h-max rounded-full whitespace-nowrap",
-        featured ? "bg-[#F8779D] border-[#F8779D] border-2 text-white" : "",
+        featured && "bg-[#F8779D] border-[#F8779D] border-2 text-white",
       )}
     >
       {text}
@@ -100,111 +100,106 @@ export default function SessionPage({ params }: SessionProps) {
     videos.map(e => e.title),
   ).bestMatch
 
+  const videoId = videos.find(e => e.title === recordingTitle.target)?.id
+
+  if (!videoId) {
+    throw new Error(`Video "${recordingTitle.target}" not found`)
+  }
+
   return (
     <div className="bg-[#f4f6f8]">
       <div className="container">
         <div className="py-10">
           <section className="text-[#333333] min-h-[80vh] flex-col mx-auto px-2 xs:px-0 lg:justify-between justify-center md:container">
-            <div className="flex flex-col lg:px-0">
-              <BackLink year="2024" kind="schedule" />
-
-              {recordingTitle.rating > 0.5 && (
-                <iframe
-                  className="aspect-video max-w-[1000px] mx-auto size-full rounded-md"
-                  src={`https://youtube.com/embed/${
-                    videos.find(e => e.title === recordingTitle.target)?.id
-                  }`}
-                  title={recordingTitle.target}
-                  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
-                  allowFullScreen
-                />
-              )}
-
-              <div className="mt-10 flex flex-col self-center prose lg:prose-lg sm:space-y-4">
-                <div className="space-y-5">
-                  <div className="flex gap-3 flex-wrap">
-                    <Tag text={eventType} featured />
-                    <Tag text={event.audience} />
-                    <Tag text={event.event_subtype} />
-                  </div>
-                  <h1 className="mt-0 text-2xl lg:text-3xl font-medium">
-                    {eventTitle}
-                  </h1>
-                  <span className="text-[#333333]">
-                    {format(
-                      parseISO(event.event_start),
-                      "EEEE, MMMM d / hh:mmaaaa 'PDT'",
-                    )}{" "}
-                    - {format(parseISO(event.event_end), "hh:mmaaaa 'PDT'")}
-                  </span>
-                </div>
-                <div className="flex flex-wrap lg:flex-row flex-col gap-5 mt-8">
-                  {event.speakers!.map(speaker => (
-                    <div
-                      className={`flex items-center gap-3 w-full ${event?.speakers?.length || 0 > 1 ? "max-w-[320px]" : ""}`}
-                      key={speaker.username}
-                    >
-                      <Avatar
-                        className="lg:size-[120px] size-[100px] rounded-full"
-                        avatar={speaker.avatar}
-                        name={speaker.name}
-                      />
-
-                      <div className="flex flex-col lg:gap-1 gap-1.5">
-                        <a
-                          href={`/conf/2024/speakers/${speaker.username}`}
-                          className="text-xl mt-0 font-bold text-[#333333] underline"
-                        >
-                          {speaker.name}
-                        </a>
-
-                        <span className="font-normal">
-                          <span className="font-semibold">
-                            {speaker.company}
-                          </span>
-                          {speaker.company && ", "}
-                          {speaker.position}
-                        </span>
-                        {speaker.socialurls?.length ? (
-                          <div className="mt-0 text-[#333333]">
-                            <div className="flex space-x-2">
-                              {speaker.socialurls.map(social => (
-                                <a
-                                  key={social.url}
-                                  href={social.url}
-                                  target="_blank"
-                                  rel="noreferrer"
-                                  className="flex items-center text-black"
-                                >
-                                  <SocialMediaIcon
-                                    service={
-                                      social.service.toLowerCase() as SocialMediaIconServiceType
-                                    }
-                                  />
-                                </a>
-                              ))}
-                            </div>
-                          </div>
-                        ) : null}
-                      </div>
-                    </div>
-                  ))}
+            <BackLink year="2024" kind="schedule" />
+            <iframe
+              className="aspect-video w-full max-w-4xl mx-auto rounded-md mt-6"
+              src={`https://youtube.com/embed/${videoId}`}
+              title={recordingTitle.target}
+              allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+              allowFullScreen
+            />
+
+            <div className="mt-10 flex flex-col self-center prose lg:prose-lg sm:space-y-4 mx-auto">
+              <div className="space-y-5">
+                <div className="flex gap-3 flex-wrap">
+                  <Tag text={eventType} featured />
+                  <Tag text={event.audience} />
+                  <Tag text={event.event_subtype} />
                 </div>
-                <p>{event.description}</p>
-
-                <div className="py-8">
-                  {event.files?.map(({ path }) => (
-                    <div key={path}>
-                      <a href={path} target="_blank" rel="noreferrer">
-                        View Full PDF{" "}
-                        <span className="font-sans font-light text-2xl">
-                          ↗
-                        </span>
+                <h1 className="mt-0 text-2xl lg:text-3xl font-medium">
+                  {eventTitle}
+                </h1>
+                <span className="text-[#333333]">
+                  {format(
+                    parseISO(event.event_start),
+                    "EEEE, MMMM d / hh:mmaaaa 'PDT'",
+                  )}{" "}
+                  - {format(parseISO(event.event_end), "hh:mmaaaa 'PDT'")}
+                </span>
+              </div>
+              <div className="flex flex-wrap lg:flex-row flex-col gap-5 mt-8">
+                {event.speakers!.map(speaker => (
+                  <div
+                    className={`flex items-center gap-3 w-full ${event?.speakers?.length || 0 > 1 ? "max-w-[320px]" : ""}`}
+                    key={speaker.username}
+                  >
+                    <Avatar
+                      className="lg:size-[120px] size-[100px] rounded-full"
+                      avatar={speaker.avatar}
+                      name={speaker.name}
+                    />
+
+                    <div className="flex flex-col lg:gap-1 gap-1.5">
+                      <a
+                        href={`/conf/2024/speakers/${speaker.username}`}
+                        className="text-xl mt-0 font-bold text-[#333333] underline"
+                      >
+                        {speaker.name}
                       </a>
-                      <iframe src={path} className="aspect-video size-full" />
+
+                      <span className="font-normal">
+                        <span className="font-semibold">{speaker.company}</span>
+                        {speaker.company && ", "}
+                        {speaker.position}
+                      </span>
+                      {speaker.socialurls?.length ? (
+                        <div className="mt-0 text-[#333333]">
+                          <div className="flex space-x-2">
+                            {speaker.socialurls.map(social => (
+                              <a
+                                key={social.url}
+                                href={social.url}
+                                target="_blank"
+                                rel="noreferrer"
+                                className="flex items-center text-black"
+                              >
+                                <SocialMediaIcon
+                                  service={
+                                    social.service.toLowerCase() as SocialMediaIconServiceType
+                                  }
+                                />
+                              </a>
+                            ))}
+                          </div>
+                        </div>
+                      ) : null}
                     </div>
-                  ))}
-                </div>
+                  </div>
+                ))}
+              </div>
+              <p>{event.description}</p>
+
+              <div className="py-8">
+                {event.files?.map(({ path }) => (
+                  <div key={path}>
+                    <a href={path} target="_blank" rel="noreferrer">
+                      View Full PDF{" "}
+                      <span className="font-sans font-light text-2xl">↗</span>
+                    </a>
+                    <iframe src={path} className="aspect-video size-full" />
+                  </div>
+                ))}
               </div>
             </div>
           </section>
diff --git a/src/code/services/hive.md b/src/code/services/hive.md
new file mode 100644
index 0000000000..1841523ddb
--- /dev/null
+++ b/src/code/services/hive.md
@@ -0,0 +1,6 @@
+---
+name: Hive
+description: Hive is a fully open-source schema registry, analytics and gateway for GraphQL federation and other GraphQL APIs.
+url: https://the-guild.dev/graphql/hive
+github: graphql-hive/platform
+---
diff --git a/src/code/services/prisma.md b/src/code/services/prisma.md
deleted file mode 100644
index 9daa18587e..0000000000
--- a/src/code/services/prisma.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: Prisma
-description: Next-generation Node.js and TypeScript ORM with a built-in data loader, which can be used when building GraphQL backends. For more information, go to https://www.prisma.io/graphql
-url: https://www.prisma.io
-github: prisma/prisma
----
diff --git a/src/code/services/tipe.md b/src/code/services/tipe.md
deleted file mode 100644
index 0ab64d39d8..0000000000
--- a/src/code/services/tipe.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-name: Tipe
-description: A SaaS (Software as a Service) content management system that allows you to create your content with powerful editing tools and access it from anywhere with a GraphQL or REST API.
-url: https://tipe.io
----
diff --git a/src/code/tools/hive/gateways-supergraphs/hive.md b/src/code/tools/hive/gateways-supergraphs/hive.md
new file mode 100644
index 0000000000..467c6d4f92
--- /dev/null
+++ b/src/code/tools/hive/gateways-supergraphs/hive.md
@@ -0,0 +1,6 @@
+---
+name: Hive Gateway
+description: Hive Gateway can act as a GraphQL federation gateway or a proxy for any GraphQL service.
+url: https://the-guild.dev/graphql/hive
+github: graphql-hive/gateway
+---
diff --git a/src/components/marked/swapi-schema.tsx b/src/components/marked/swapi-schema.tsx
index f1b5dcdbe2..0f56f9be3e 100644
--- a/src/components/marked/swapi-schema.tsx
+++ b/src/components/marked/swapi-schema.tsx
@@ -17,7 +17,7 @@ const typeDefs = /* GraphQL */ `
     mutation: Mutation
   }
 
-  # The query type, represents all of the entry points into our object graph
+  "The query type, represents all of the entry points into our object graph"
   type Query {
     hero(episode: Episode): Character
     reviews(episode: Episode!): [Review]
@@ -28,155 +28,155 @@ const typeDefs = /* GraphQL */ `
     starship(id: ID!): Starship
   }
 
-  # The mutation type, represents all updates we can make to our data
+  "The mutation type, represents all updates we can make to our data"
   type Mutation {
     createReview(episode: Episode, review: ReviewInput!): Review
   }
 
-  # The episodes in the Star Wars trilogy
+  "The episodes in the Star Wars trilogy"
   enum Episode {
-    # Star Wars Episode IV: A New Hope, released in 1977.
+    "Star Wars Episode IV: A New Hope, released in 1977."
     NEWHOPE
 
-    # Star Wars Episode V: The Empire Strikes Back, released in 1980.
+    "Star Wars Episode V: The Empire Strikes Back, released in 1980."
     EMPIRE
 
-    # Star Wars Episode VI: Return of the Jedi, released in 1983.
+    "Star Wars Episode VI: Return of the Jedi, released in 1983."
     JEDI
   }
 
-  # A character from the Star Wars universe
+  "A character from the Star Wars universe"
   interface Character {
-    # The ID of the character
+    "The ID of the character"
     id: ID!
 
-    # The name of the character
+    "The name of the character"
     name: String!
 
-    # The friends of the character, or an empty list if they have none
+    "The friends of the character, or an empty list if they have none"
     friends: [Character]
 
-    # The friends of the character exposed as a connection with edges
+    "The friends of the character exposed as a connection with edges"
     friendsConnection(first: Int, after: ID): FriendsConnection!
 
-    # The movies this character appears in
+    "The movies this character appears in"
     appearsIn: [Episode]!
   }
 
-  # Units of height
+  "Units of height"
   enum LengthUnit {
-    # The standard unit around the world
+    "The standard unit around the world"
     METER
 
-    # Primarily used in the United States
+    "Primarily used in the United States"
     FOOT
   }
 
-  # A humanoid creature from the Star Wars universe
+  "A humanoid creature from the Star Wars universe"
   type Human implements Character {
-    # The ID of the human
+    "The ID of the human"
     id: ID!
 
-    # What this human calls themselves
+    "What this human calls themselves"
     name: String!
 
-    # Height in the preferred unit, default is meters
+    "Height in the preferred unit, default is meters"
     height(unit: LengthUnit = METER): Float
 
-    # Mass in kilograms, or null if unknown
+    "Mass in kilograms, or null if unknown"
     mass: Float
 
-    # This human's friends, or an empty list if they have none
+    "This human's friends, or an empty list if they have none"
     friends: [Character]
 
-    # The friends of the human exposed as a connection with edges
+    "The friends of the human exposed as a connection with edges"
     friendsConnection(first: Int, after: ID): FriendsConnection!
 
-    # The movies this human appears in
+    "The movies this human appears in"
     appearsIn: [Episode]!
 
-    # A list of starships this person has piloted, or an empty list if none
+    "A list of starships this person has piloted, or an empty list if none"
     starships: [Starship]
   }
 
-  # An autonomous mechanical character in the Star Wars universe
+  "An autonomous mechanical character in the Star Wars universe"
   type Droid implements Character {
-    # The ID of the droid
+    "The ID of the droid"
     id: ID!
 
-    # What others call this droid
+    "What others call this droid"
     name: String!
 
-    # This droid's friends, or an empty list if they have none
+    "This droid's friends, or an empty list if they have none"
     friends: [Character]
 
-    # The friends of the droid exposed as a connection with edges
+    "The friends of the droid exposed as a connection with edges"
     friendsConnection(first: Int, after: ID): FriendsConnection!
 
-    # The movies this droid appears in
+    "The movies this droid appears in"
     appearsIn: [Episode]!
 
-    # This droid's primary function
+    "This droid's primary function"
     primaryFunction: String
   }
 
-  # A connection object for a character's friends
+  "A connection object for a character's friends"
   type FriendsConnection {
-    # The total number of friends
+    "The total number of friends"
     totalCount: Int
 
-    # The edges for each of the character's friends.
+    "The edges for each of the character's friends."
     edges: [FriendsEdge]
 
-    # A list of the friends, as a convenience when edges are not needed.
+    "A list of the friends, as a convenience when edges are not needed."
     friends: [Character]
 
-    # Information for paginating this connection
+    "Information for paginating this connection"
     pageInfo: PageInfo!
   }
 
-  # An edge object for a character's friends
+  "An edge object for a character's friends"
   type FriendsEdge {
-    # A cursor used for pagination
+    "A cursor used for pagination"
     cursor: ID!
 
-    # The character represented by this friendship edge
+    "The character represented by this friendship edge"
     node: Character
   }
 
-  # Information for paginating this connection
+  "Information for paginating this connection"
   type PageInfo {
     startCursor: ID
     endCursor: ID
     hasNextPage: Boolean!
   }
 
-  # Represents a review for a movie
+  "Represents a review for a movie"
   type Review {
-    # The number of stars this review gave, 1-5
+    "The number of stars this review gave, 1-5"
     stars: Int!
 
-    # Comment about the movie
+    "Comment about the movie"
     commentary: String
   }
 
-  # The input object sent when someone is creating a new review
+  "The input object sent when someone is creating a new review"
   input ReviewInput {
-    # 0-5 stars
+    "0-5 stars"
     stars: Int!
 
-    # Comment about the movie, optional
+    "Comment about the movie, optional"
     commentary: String
   }
 
   type Starship {
-    # The ID of the starship
+    "The ID of the starship"
     id: ID!
 
-    # The name of the starship
+    "The name of the starship"
     name: String!
 
-    # Length of the starship, along the longest axis
+    "Length of the starship, along the longest axis"
     length(unit: LengthUnit = METER): Float
   }
 
diff --git a/src/pages/blog/2024-11-04-fosdem-2025.md b/src/pages/blog/2024-11-04-fosdem-2025.md
new file mode 100644
index 0000000000..644fc91075
--- /dev/null
+++ b/src/pages/blog/2024-11-04-fosdem-2025.md
@@ -0,0 +1,55 @@
+---
+title: "Call for Participation for FOSDEM API & Friends devroom"
+tags: ["blog"]
+date: 2024-11-04
+byline: Jem Gillam
+---
+
+We are excited to announce the [Call for Participation for the FOSDEM 2025 APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom](https://pretalx.fosdem.org/fosdem-2025/cfp).
+
+## What is FOSDEM?
+
+[FOSDEM](https://fosdem.org/) is a two day, free and non-commercial event held in Brussels, Belguim, in February each year. It brings together over 8,000 software developers to meet, share ideas and collaborate on free and open source software. The FOSDEM team feel it is very important that developers get to meet offline and so run Devrooms to facilitate this - rooms with talks, panels and showcases centered around one theme where developers can share ideas and publicly present their latest findings, news and projects in a collaborative atmosphere.
+
+## What is the APIs & Friends Devroom?
+
+A platform for developers, technologists, and enthusiasts to come together to discuss, learn, and collaborate on topics around APIs and Open Source. Open collaboration is a driving force behind APIs and open-source projects, and we look forward to talks on community-driven technologies such as OpenAPI, GraphQL, AsyncAPI, gRPC and webhooks.
+
+## Suggested Topics
+
+We welcome submissions about, but not limited to:
+
+- Your favourite Open Source project: tooling, frameworks, SDKs, API gateway, etc.
+- Topics related to API standards such as OpenAPI, GraphQL, JSON Schema or AsyncAPI.
+- API Design Principles: best practices for designing clean, efficient, and developer-friendly APIs.
+- Topics related to versioning, authentication, rate limiting, and error handling.
+- Real-world API Use Cases.
+- Developer Experience and API Documentation.
+
+## Important Dates
+
+- Sunday Dec 1st 2024: Submission deadline (Closes at midnight Brussels time)
+- Sunday Dec 15th 2024: Announcement of selected talks
+- Sunday Feb 2nd 2025: Devroom at 1pm, in person at ULB Solbosch Campus, Brussels, Belguim
+
+## Recording
+
+Please be aware of the fact that, barring any technical difficulties, devroom
+talks at FOSDEM will be recorded. By submitting a proposal you agree to be
+recorded and to have your talk made available from the FOSDEM video platform.
+
+## How to submit a talk
+
+- Talk submissions can be 20 to 25 minutes, allowing a short Q&A time to fill the rest of the 30 minute slot
+- Shorter (lightning) talks should be 10-12 minutes and should indicate "lightning talk" in the description
+- Go to [FOSDEM pretalx](https://pretalx.fosdem.org/fosdem-2025/cfp) website
+- Select ‘APIs: GraphQL, OpenAPI, AsyncAPI, and friends’ from the ‘Track’ field
+
+## Code of Conduct
+
+The code of conduct for FOSDEM is available at https://fosdem.org/2025/practical/conduct/
+
+## Questions
+
+You can reach the devroom organisers at: api-devroom-manager AT fosdem.org
+The APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom is organised by volunteers who also ran the API & Friends devroom last year, and joining forces with members of the GraphQL Technical Steering Committee to bring a GraphQL focus as well as fostering collaboration with folks representing OpenAPI and AsyncAPI projects.
diff --git a/src/pages/community/resources/books.mdx b/src/pages/community/resources/books.mdx
index 6a2b96d609..ca8486c6ff 100644
--- a/src/pages/community/resources/books.mdx
+++ b/src/pages/community/resources/books.mdx
@@ -8,3 +8,4 @@
 - [Hands-on Full-Stack Web Development with GraphQL and React](https://www.packtpub.com/web-development/hands-full-stack-web-development-graphql-and-react) by Sebastian Grebe
 - [The Road to GraphQL](https://www.robinwieruch.de/the-road-to-graphql-book/) by Robin Wieruch
 - [Production Ready GraphQL](https://book.productionreadygraphql.com/) by Marc-Andre Giroux
+- [GraphQL Best Practices: Hands-on experience with schema design, security, and error handling for developers](https://www.amazon.com/dp/B0D9H7MJQV) by Artur Czemiel, Nov 2024
diff --git a/src/pages/learn/_meta.ts b/src/pages/learn/_meta.ts
index 4affaab60a..36d579e53c 100644
--- a/src/pages/learn/_meta.ts
+++ b/src/pages/learn/_meta.ts
@@ -8,6 +8,7 @@ export default {
   schema: "Schemas and Types",
   validation: "",
   execution: "",
+  response: "",
   introspection: "",
   "-- 2": {
     type: "separator",
@@ -20,4 +21,5 @@ export default {
   pagination: "",
   "global-object-identification": "",
   caching: "",
+  security: "",
 }
diff --git a/src/pages/learn/authorization.mdx b/src/pages/learn/authorization.mdx
index e4922ef422..2c7baeeebb 100644
--- a/src/pages/learn/authorization.mdx
+++ b/src/pages/learn/authorization.mdx
@@ -1,52 +1,92 @@
 # Authorization
 
-> Delegate authorization logic to the business logic layer
+<p className="learn-subtitle">Delegate authorization logic to the business logic layer</p>
+
+Most APIs will need to secure access to certain types of data depending on who requested it, and GraphQL is no different. GraphQL execution should begin after [authentication](/graphql-js/authentication-and-express-middleware/) middleware confirms the user's identity and passes that information to the GraphQL layer. But after that, you still need to determine if the authenticated user is allowed to view the data provided by the specific fields that were included in the request. On this page, we'll explore how a GraphQL schema can support authorization.
+
+## Type and field authorization
 
 Authorization is a type of business logic that describes whether a given user/session/context has permission to perform an action or see a piece of data. For example:
 
 _"Only authors can see their drafts"_
 
-Enforcing this kind of behavior should happen in the [business logic layer](/learn/thinking-in-graphs/#business-logic-layer). It is tempting to place authorization logic in the GraphQL layer like so:
+Enforcing this behavior should happen in the [business logic layer](/learn/thinking-in-graphs/#business-logic-layer). Let's consider the following `Post` type defined in a schema:
+ 
+```graphql
+type Post {
+  authorId: ID!
+  body: String
+}
+```
+
+In this example, we can imagine that when a request initially reaches the server, authentication middleware will first check the user's credentials and add information about their identity to the `context` object of the GraphQL request so that this data is available in every field resolver for the duration of its execution.
+
+If a post's body should only be visible to the user who authored it, then we will need to check that the authenticated user's ID matches the post's `authorId` value. It may be tempting to place authorization logic in the resolver for the post's `body` field like so:
 
 ```js
-const postType = new GraphQLObjectType({
-  name: 'Post',
-  fields: {
-    body: {
-      type: GraphQLString,
-      resolve(post, args, context, { rootValue }) {
-        // return the post body only if the user is the post's author
-        if (context.user && (context.user.id === post.authorId)) {
-          return post.body
-        }
-        return null
-      }
-    }
+function Post_body(obj, args, context, info) {
+  // return the post body only if the user is the post's author
+  if (context.user && (context.user.id === obj.authorId)) {
+    return obj.body
   }
-})
+  return null
+}
 ```
 
-Notice that we define "author owns a post" by checking whether the post's `authorId` field equals the current user’s `id`. Can you spot the problem? We would need to duplicate this code for each entry point into the service. Then if the authorization logic is not kept perfectly in sync, users could see different data depending on which API they use. Yikes! We can avoid that by having a [single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for authorization.
+Notice that we define "author owns a post" by checking whether the post's `authorId` field equals the current user’s `id`. Can you spot the problem? We would need to duplicate this code for each entry point into the service. Then if the authorization logic is not kept perfectly in sync, users could see different data depending on which API they use. Yikes! We can avoid that by having a [single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for authorization, instead of putting it the GraphQL layer.
 
-Defining authorization logic inside the resolver is fine when learning GraphQL or prototyping. However, for a production codebase, delegate authorization logic to the business logic layer. Here’s an example:
+Defining authorization logic inside the resolver is fine when learning GraphQL or prototyping. However, for a production codebase, delegate authorization logic to the business logic layer. Here’s an example of how authorization of the `Post` type's fields could be implemented separately:
 
 ```js
-// Authorization logic lives inside postRepository
-const postRepository = require('postRepository');
-
-const postType = new GraphQLObjectType({
-  name: 'Post',
-  fields: {
-    body: {
-      type: GraphQLString,
-      resolve(post, args, context, { rootValue }) {
-        return postRepository.getBody(context.user, post)
-      }
+// authorization logic lives inside `postRepository`
+export const postRepository = {
+  getBody({ user, post }) {
+    if (user?.id && (user.id === post.authorId)) {
+      return post.body
     }
+    return null
   }
-})
+}
+```
+
+The resolver function for the post's `body` field would then call a `postRepository` method instead of implementing the authorization logic directly:
+
+```js
+import { postRepository } from 'postRepository'
+
+function Post_body(obj, args, context, info) {
+  // return the post body only if the user is the post's author
+  return postRepository.getBody({ user: context.user, post: obj })
+}
 ```
 
-In the example above, we see that the business logic layer requires the caller to provide a user object. If you are using GraphQL.js, the User object should be populated on the `context` argument or `rootValue` in the fourth argument of the resolver.
+In the example above, we see that the business logic layer requires the caller to provide a user object, which is available in the `context` object for the GraphQL request. We recommend passing a fully-hydrated user object instead of an opaque token or API key to your business logic layer. This way, we can handle the distinct concerns of [authentication](/graphql-js/authentication-and-express-middleware/) and authorization in different stages of the request processing pipeline.
+
+## Using type system directives
+
+In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. In general, it is recommended to perform all authorization logic in that layer, but if you decide to implement authorization in the GraphQL layer instead then this may be accommplished using [type system directives](/learn/schema/#directives).
+
+For example, a directive such as `@auth` could be defined in the schema with arguments that indicate what roles or permissions a user must have to access the data provided by the types and fields where the directive is applied:
+
+```graphql
+directive @auth(rule: Rule) on FIELD_DEFINITION
+
+enum Rule {
+  IS_AUTHOR
+}
+
+type Post {
+  authorId: ID!
+  body: String @auth(rule: IS_AUTHOR)
+}
+```
+
+It would be up to the GraphQL implementation to determine how an `@auth` directive affects execution when a client makes a request that includes the `body` field for `Post` type. However, the authorization logic should remain delegated to the business logic layer.
+
+## Recap
+
+To recap these recommendations for authorization in GraphQL:
 
-We recommend passing a fully-hydrated User object instead of an opaque token or API key to your business logic layer. This way, we can handle the distinct concerns of [authentication](/graphql-js/authentication-and-express-middleware/) and authorization in different stages of the request processing pipeline.
+- Authorization logic should be delegated to the business logic layer, not the GraphQL layer
+- After execution begins, a GraphQL server should make decisions about whether the client that made the request is authorized to access data for the included fields
+- Type system directives may be defined and added to the types and fields in a schema to apply generalized authorization rules
diff --git a/src/pages/learn/execution.mdx b/src/pages/learn/execution.mdx
index 1e04bbf9f9..5fca44a03a 100644
--- a/src/pages/learn/execution.mdx
+++ b/src/pages/learn/execution.mdx
@@ -1,8 +1,14 @@
+import { Callout } from "nextra/components"
+
 # Execution
 
-After being validated, a GraphQL query is executed by a GraphQL server which returns a result that mirrors the shape of the requested query, typically as JSON.
+<p className="learn-subtitle">Learn how GraphQL provides data for requested fields</p>
+
+After a parsed document is [validated](/learn/validation/), a client's request will be [executed](https://spec.graphql.org/draft/#sec-Execution) by the GraphQL server and the returned result will mirror the shape of the requested query. On this page, you'll learn about the execution phase of GraphQL operations where data is read from or written to an existing source depending on what fields are requested by a client.
+
+## Field resolvers
 
-GraphQL cannot execute a query without a type system, let's use an example type system to illustrate executing a query. This is a part of the same type system used throughout the examples in these articles:
+GraphQL cannot execute operations without a type system, so let's use an example type system to illustrate executing a query. This is a part of the same type system used throughout the examples in this guide:
 
 ```graphql
 type Query {
@@ -26,11 +32,11 @@ type Starship {
 }
 ```
 
-In order to describe what happens when a query is executed, let's use an example to walk through.
+To describe what happens when a query is executed, let's walk through an example:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   human(id: 1002) {
     name
     appearsIn
@@ -41,66 +47,66 @@ In order to describe what happens when a query is executed, let's use an example
 }
 ```
 
-You can think of each field in a GraphQL query as a function or method of the previous type which returns the next type. In fact, this is exactly how GraphQL works. Each field on each type is backed by a function called the _resolver_ which is provided by the GraphQL server developer. When a field is executed, the corresponding _resolver_ is called to produce the next value.
+You can think of each field in a GraphQL query as a function or method of the previous type which returns the next type. This is exactly how GraphQL works—each field on each type is backed by a _resolver function_ that is written by the GraphQL server developer. When a field is executed, the corresponding resolver is called to produce the next value.
 
-If a field produces a scalar value like a string or number, then the execution completes. However if a field produces an object value then the query will contain another selection of fields which apply to that object. This continues until scalar values are reached. GraphQL queries always end at scalar values.
+If a field produces a scalar value like a string or number, then the execution completes. However, if a field produces an object value then the query will contain another selection of fields that apply to that object. This continues until the leaf values are reached. GraphQL queries always end at Scalar or Enum types.
 
-## Root fields & resolvers
+## Root fields and resolvers
 
-At the top level of every GraphQL server is a type that represents all of the possible entry points into the GraphQL API, it's often called the _Root_ type or the _Query_ type.
+At the top level of every GraphQL server is an Object type that represents the possible entry points into the GraphQL API, it's often called "the `query` root operation type" or the `Query` type. If the API supports mutations to write data and subscriptions to fetch real-time data as well, then it will have `Mutation` and `Subscription` types that expose fields to perform these kinds of operations too. You can learn more about these types on the [Schema and Types page](/learn/schema/#the-query-mutation-and-subscription-types).
 
-In this example, our Query type provides a field called `human` which accepts the argument `id`. The resolver function for this field likely accesses a database and then constructs and returns a `Human` object.
+In this example, our `Query` type provides a field called `human` which accepts the argument `id`. The resolver function for this field likely accesses a database and then constructs and returns a `Human` type:
 
 ```js
-Query: {
-  human(obj, args, context, info) {
-    return context.db.loadHumanByID(args.id).then(
-      userData => new Human(userData)
-    )
-  }
+function Query_human(obj, args, context, info) {
+  return context.db.loadHumanByID(args.id).then(
+    userData => new Human(userData)
+  )
 }
 ```
 
-This example is written in JavaScript, however GraphQL servers can be built in [many different languages](/code/). A resolver function receives four arguments:
+This example is written in JavaScript, however GraphQL servers can be built in [many different languages](/code/). In the reference implementation, a resolver function receives four arguments:
 
-- `obj` The previous object, which for a field on the root Query type is often not used.
-- `args` The arguments provided to the field in the GraphQL query.
-- `context` A value which is provided to every resolver and holds important contextual information like the currently logged in user, or access to a database.
-- `info` A value which holds field-specific information relevant to the current query as well as the schema details, also refer to [type GraphQLResolveInfo for more details](/graphql-js/type/#graphqlobjecttype).
+- `obj`: The previous object (for a field on the root `Query` type, this argument is often not used).
+- `args`: The arguments provided to the field in the GraphQL operation.
+- `context`: A value provided to every resolver that may hold important contextual information like the currently logged in user, or access to a database.
+- `info`: generally only used in advanced use-cases, this is a value holding field-specific information relevant to the current operation as well as the schema details; refer to [type GraphQLResolveInfo](/graphql-js/type/#graphqlobjecttype) for more details.
+
+<Callout type="info">
+Note that while a query operation could technically write data to the underlying data system during its execution, mutation operations are conventionally used for requests that produce side effects during their execution. And because mutation operations produce side effects, GraphQL implementations can be expected to execute these fields serially.
+</Callout>
 
 ## Asynchronous resolvers
 
-Let's take a closer look at what's happening in this resolver function.
+Let's take a closer look at what's happening in this resolver function:
 
 ```js
-human(obj, args, context, info) {
+function Query_human(obj, args, context, info) {
   return context.db.loadHumanByID(args.id).then(
     userData => new Human(userData)
   )
 }
 ```
 
-The `context` is used to provide access to a database which is used to load the data for a user by the `id` provided as an argument in the GraphQL query. Since loading from a database is an asynchronous operation, this returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise). In JavaScript, Promises are used to work with asynchronous values, but the same concept exists in many languages, often called _Futures_, _Tasks_ or _Deferred_. When the database returns, we can construct and return a new `Human` object.
+The `id` argument in the GraphQL query specifies the user whose data is requested, while `context` provides access to retrieve this data from a database. Since loading from a database is an asynchronous operation, this returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise). In JavaScript, Promises are used to work with asynchronous values, but the same concept exists in many languages, often called _Futures_, _Tasks_, or _Deferred_. When the database returns the data, we can construct and return a new `Human` object.
 
-Notice that while the resolver function needs to be aware of Promises, the GraphQL query does not. It simply expects the `human` field to return something which it can then ask the `name` of. During execution, GraphQL will wait for Promises, Futures, and Tasks to complete before continuing and will do so with optimal concurrency.
+Notice that while the resolver function needs to be aware of Promises, the GraphQL query does not. It simply expects the `human` field to return something that can be further resolved to a scalar `name` value. During execution, GraphQL will wait for Promises, Futures, and Tasks to be completed before continuing and will do so with optimal concurrency.
 
 ## Trivial resolvers
 
-Now that a `Human` object is available, GraphQL execution can continue with the fields requested on it.
+Now that a `Human` object is available, GraphQL execution can continue with the fields requested for this type:
 
 ```js
-Human: {
-  name(obj, args, context, info) {
-    return obj.name
-  }
+function Human_name(obj, args, context, info) {
+  return obj.name
 }
 ```
 
-A GraphQL server is powered by a type system which is used to determine what to do next. Even before the `human` field returns anything, GraphQL knows that the next step will be to resolve fields on the `Human` type since the type system tells it that the `human` field will return a `Human`.
+A GraphQL server is powered by a type system that is used to determine what to do next. Even before the `human` field returns anything, GraphQL knows the next step will be to resolve fields on the `Human` type since the type system tells it that the `human` field will return this output type.
 
-Resolving the name in this case is very straight-forward. The name resolver function is called and the `obj` argument is the `new Human` object returned from the previous field. In this case, we expect that Human object to have a `name` property which we can read and return directly.
+Resolving the name in this case is straightforward. The name resolver function is called and the `obj` argument is the new `Human` object returned from the previous field. In this case, we expect this object to have a `name` property, which we can read and return directly.
 
-In fact, many GraphQL libraries will let you omit resolvers this simple and will just assume that if a resolver isn't provided for a field, that a property of the same name should be read and returned.
+Many GraphQL libraries let you omit resolvers this simple, assuming that if a resolver isn't provided for a field, a property of the same name should be read and returned.
 
 ## Scalar coercion
 
@@ -114,39 +120,37 @@ Human: {
 }
 ```
 
-Notice that our type system claims `appearsIn` will return Enum values with known values, however this function is returning numbers! Indeed if we look up at the result we'll see that the appropriate Enum values are being returned. What's going on?
+Notice that our type system claims `appearsIn` will return Enum types with known values, however, this function is returning numbers! Indeed if we look up at the result we'll see that the appropriate values for the Enum type are being returned. What's going on?
 
-This is an example of scalar coercion. The type system knows what to expect and will convert the values returned by a resolver function into something that upholds the API contract. In this case, there may be an Enum defined on our server which uses numbers like `4`, `5`, and `6` internally, but represents them as Enum values in the GraphQL type system.
+This is an example of _scalar coercion_. The type system knows what to expect and will convert the values returned by a resolver function into something that upholds the API contract. In this case, there may be an Enum type defined on our server that uses numbers like `4`, `5`, and `6` internally, but represents them as the expected values in the GraphQL type system.
 
 ## List resolvers
 
-We've already seen a bit of what happens when a field returns a list of things with the `appearsIn` field above. It returned a _list_ of enum values, and since that's what the type system expected, each item in the list was coerced to the appropriate enum value. What happens when the `starships` field is resolved?
+We've already seen some of what happens when a field returns a list of things with the `appearsIn` field above. It returned a [List type](/learn/schema/#lists) containing Enum type values, and since that's what the type system expected, each item in the list was coerced to the appropriate value. What happens when the `starships` field is resolved?
 
 ```js
-Human: {
-  starships(obj, args, context, info) {
-    return obj.starshipIDs.map(
-      id => context.db.loadStarshipByID(id).then(
-        shipData => new Starship(shipData)
-      )
+function Human_starships (obj, args, context, info) {
+  return obj.starshipIDs.map(
+    id => context.db.loadStarshipByID(id).then(
+      shipData => new Starship(shipData)
     )
-  }
+  )
 }
 ```
 
-The resolver for this field is not just returning a Promise, it's returning a _list_ of Promises. The `Human` object had a list of ids of the `Starships` they piloted, but we need to go load all of those ids to get real Starship objects.
+The resolver for this field is not just returning a Promise, it's returning a _list_ of Promises. The `Human` object had a list of IDs of the `Starships` they piloted, but we need to load all of those IDs to get real Starship objects.
 
-GraphQL will wait for all of these Promises concurrently before continuing, and when left with a list of objects, it will concurrently continue yet again to load the `name` field on each of these items.
+GraphQL will wait for all of these Promises concurrently before continuing, and when left with a list of objects, it will continue yet again to load the `name` field on each of these items concurrently.
 
 ## Producing the result
 
-As each field is resolved, the resulting value is placed into a key-value map with the field name (or alias) as the key and the resolved value as the value. This continues from the bottom leaf fields of the query all the way back up to the original field on the root Query type. Collectively these produce a structure that mirrors the original query which can then be sent (typically as JSON) to the client which requested it.
+As each field is resolved, the resulting value is placed into a key-value map with the field name (or alias) as the key and the resolved value as the value. This continues from the bottom leaf fields of the query back up to the original field on the root `Query` type. Collectively these produce a structure that mirrors the original query which can then be sent (typically as JSON) to the client that requested it.
 
 Let's take one last look at the original query to see how all these resolving functions produce a result:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   human(id: 1002) {
     name
     appearsIn
@@ -156,3 +160,18 @@ Let's take one last look at the original query to see how all these resolving fu
   }
 }
 ```
+
+As we can see, each field in the nested selection sets resolves to a scalar leaf value during execution of the query.
+
+## Next steps
+
+To recap what we've learned about execution:
+
+- Each field in a GraphQL type system will have a corresponding resolver function that provides data for the field from an existing data source
+- Execution begins at the top-level `Query`, `Mutation`, or `Subscription` fields
+- Resolvers may execute asynchronously
+- Scalar coercion converts values into the types expected by the schema
+- When a field on an Object type returns a List type of other objects, additional data may need to be fetched from the underlying data source to transform any foreign key-like references (such as IDs) into the related objects
+- Once all of the requested fields have been resolved to the expected leaf values, the result is sent to the client, typically as JSON
+
+Now that we understand how operations are executed, we can move to the last stage of the lifecycle of a GraphQL request where the [response](/learn/response/) is delivered to a client.
\ No newline at end of file
diff --git a/src/pages/learn/index.mdx b/src/pages/learn/index.mdx
index c5054ea04c..ac6ba9c291 100644
--- a/src/pages/learn/index.mdx
+++ b/src/pages/learn/index.mdx
@@ -36,7 +36,7 @@ function User_name(user, args, context, info) {
 }
 ```
 
-In the example above, the function that provides data for the `me` field on the `Query` type uses information about the authenticated user who made the request, while the the `name` field on the `User` type is populated by using that user's ID to fetch their full name from a database.
+In the example above, the function that provides data for the `me` field on the `Query` type uses information about the authenticated user who made the request, while the `name` field on the `User` type is populated by using that user's ID to fetch their full name from a database.
 
 ## Query exactly what you need
 
diff --git a/src/pages/learn/introspection.mdx b/src/pages/learn/introspection.mdx
index a4cfa7462b..f7b36e5f4b 100644
--- a/src/pages/learn/introspection.mdx
+++ b/src/pages/learn/introspection.mdx
@@ -1,23 +1,41 @@
 # Introspection
 
-It's often useful to ask a GraphQL schema for information about what
-queries it supports. GraphQL allows us to do so using the introspection
-system!
+<p className="learn-subtitle">Learn how to query information about a GraphQL schema</p>
 
-For our Star Wars example, the file
-[starWarsIntrospection-test.ts](https://github.com/graphql/graphql-js/blob/main/src/__tests__/starWarsIntrospection-test.ts)
-contains a number of queries demonstrating the introspection system, and is a
-test file that can be run to exercise the reference implementation's
-introspection system.
+It's often useful to ask a GraphQL schema for information about what features it supports. GraphQL allows us to do so using the [introspection system](https://spec.graphql.org/draft/#sec-Introspection).
 
-We designed the type system, so we know what types are available, but if
-we didn't, we can ask GraphQL, by querying the `__schema` field, always
-available on the root type of a Query. Let's do so now, and ask what types
-are available.
+Introspection queries are special kinds of queries that allow you to learn about a GraphQL API's schema, and they also help power GraphQL development tools. On this page, we'll learn how to run different queries to learn more about an underlying schema's types, fields, and descriptions.
+
+## Type name introspection
+
+We have already seen an example of introspection on the [Schemas and Types page](/learn/schema/). When querying a field that returned Union type, we included the `__typename` meta-field directly in a selection set to get the string value of the names of the different types returned by a search query. Let's look at this example again:
+
+```graphql
+# { "graphiql": true }
+query {
+  search(text: "an") {
+    __typename
+    ... on Character {
+      name
+    }
+    ... on Starship {
+      name
+    }
+  }
+}
+```
+
+We didn't add the `__typename` field to our GraphQL API explicitly—the GraphQL specification says that it must be provided to clients by a GraphQL implementation. This field can be queried for any field with an Object, Interface, or Union type as the underlying output type.
+
+## Schema introspection
+
+Introspection can do more than provide type names in a query. If you designed the type system for a GraphQL API, then you'll likely already know what types are available. But if you didn't design it, you can ask GraphQL by querying the `__schema` field, which is always available on the `query` root operation type.
+
+Let's do so now and ask what types are available in the Star Wars schema:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __schema {
     types {
       name
@@ -28,21 +46,15 @@ are available.
 
 Wow, that's a lot of types! What are they? Let's group them:
 
-- `Query`, `Character`, `Human`, `Episode`, `Droid` - These are the ones that we
-  defined in our type system.
-- `String`, `Boolean` - These are built-in scalars that the type system
-  provided.
-- `__Schema`, `__Type`, `__TypeKind`, `__Field`, `__InputValue`,
-  `__EnumValue`, `__Directive` - These all are preceded with a double
-  underscore, indicating that they are part of the introspection system.
+- Types that we defined in our type system: `Query`, `Mutation`, `Character`, `Human`, `Episode`, `Droid`, `LengthUnit`, `FriendsConnection`, `FriendsEdge`, `PageInfo`, `Review`, `ReviewInput`, `Starship`, and `SearchResult`
+- Built-in scalars that the type system provided: `Boolean`, `Float`, `ID`, `Int`, and `String`
+- Types preceded with a double underscore that are part of the introspection system: `__Schema`, `__Type`, `__TypeKind`, `__Field`, `__InputValue`, `__EnumValue`, `__Directive`, and `__DirectiveLocation`
 
-Now, let's try and figure out a good place to start exploring what queries are
-available. When we designed our type system, we specified what type all queries
-would start at; let's ask the introspection system about that!
+Now, let's try to figure out a good place to start exploring what queries are available. When we designed our type system, we specified what type all queries would start at; let's ask the introspection system about that:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __schema {
     queryType {
       name
@@ -51,31 +63,24 @@ would start at; let's ask the introspection system about that!
 }
 ```
 
-And that matches what we said in the type system section, that
-the `Query` type is where we will start! Note that the naming here
-was just by convention; we could have named our `Query` type anything
-else, and it still would have been returned here had we specified it
-was the starting type for queries. Naming it `Query`, though, is a useful
-convention.
+The result matches what we said in the [type system section](/learn/schema/#type-system)—that the `Query` type is where we will start. Note that the naming here was just by convention; we could have named our `Query` type anything else, and it still would have been returned here had we specified it was the starting type for queries. Naming it `Query`, though, is a useful convention.
 
-It is often useful to examine one specific type. Let's take a look at
-the `Droid` type:
+It is often useful to examine one specific type. Let's take a look at the `Droid` type:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Droid") {
     name
   }
 }
 ```
 
-What if we want to know more about Droid, though? For example, is it
-an interface or an object?
+But what if we want to know more about Droid? For example, is it an Interface or Object type?
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Droid") {
     name
     kind
@@ -83,12 +88,11 @@ an interface or an object?
 }
 ```
 
-`kind` returns a `__TypeKind` enum, one of whose values is `OBJECT`. If
-we asked about `Character` instead we'd find that it is an interface:
+`kind` returns a `__TypeKind` Enum type, one of whose values is `OBJECT`. If we asked about `Character` instead we'd find that it is an Interface type:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Character") {
     name
     kind
@@ -96,12 +100,11 @@ we asked about `Character` instead we'd find that it is an interface:
 }
 ```
 
-It's useful for an object to know what fields are available, so let's
-ask the introspection system about `Droid`:
+It's useful for an Object type to know what fields are available, so let's ask the introspection system about `Droid`:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Droid") {
     name
     fields {
@@ -115,20 +118,15 @@ ask the introspection system about `Droid`:
 }
 ```
 
-Those are our fields that we defined on `Droid`!
+Those are the fields that we defined on `Droid`!
 
-`id` looks a bit weird there, it has no name for the type. That's
-because it's a "wrapper" type of kind `NON_NULL`. If we queried for
-`ofType` on that field's type, we would find the `ID` type there,
-telling us that this is a non-null ID.
+`id` looks a bit weird there, it has no name for the type. That's because it's a _wrapper type_ of kind `NON_NULL`. If we queried for `ofType` on that field's type, we would find the `ID` type there, telling us this is a non-null ID.
 
-Similarly, both `friends` and `appearsIn` have no name, since they are the
-`LIST` wrapper type. We can query for `ofType` on those types, which will
-tell us what these are lists of.
+Similarly, both `friends` and `appearsIn` have no name, since they are the `LIST` wrapper type. We can query for `ofType` on those types, which will tell us what types are inside the list:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Droid") {
     name
     fields {
@@ -146,12 +144,11 @@ tell us what these are lists of.
 }
 ```
 
-Let's end with a feature of the introspection system particularly useful
-for tooling; let's ask the system for documentation!
+Let's end with a feature of the introspection system particularly useful for tooling; let's ask the system for documentation:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   __type(name: "Droid") {
     name
     description
@@ -159,12 +156,24 @@ for tooling; let's ask the system for documentation!
 }
 ```
 
-So we can access the documentation about the type system using introspection,
-and create documentation browsers, or rich IDE experiences.
+As demonstrated above, we can access the documentation about the type system using introspection and create documentation browsers or rich IDE experiences.
+
+This has just scratched the surface of the introspection system; we can query for Enum type values, what Interface types another type implements, and more. We can even introspect on the introspection system itself.
+
+To see an example of a specification-compliant GraphQL query introspection system implemented in code, you can view [src/type/introspection.ts](https://github.com/graphql/graphql-js/blob/e9b6b626f6f6aa379bb8f8c48df40d0c02a26082/src/type/introspection.ts) in the reference implementation.
+
+## Introspection in production
+
+Introspection is a useful feature of GraphQL, especially for client developers and tooling. However, for APIs intended only for your own applications, it’s typically not needed in production—required operations are usually baked into these applications at build time, making runtime introspection unnecessary.
+
+Disabling introspection in production is common in order to reduce the API’s attack surface. This is often part of a broader API security strategy, which may also include authentication and authorization, operation safe-listing (or a range of alternative protections, such as depth-limiting, breadth-limiting, alias limits, cycle rejection, cost analysis, etc.), execution timeouts, and more.
+
+## Next steps
+
+To recap what we've learned about introspection:
+
+- Type names can be queried in a field selection set for an Object, Interface, or Union type using the `__typename` meta-field
+- Information about the elements of a GraphQL schema can be queried using the `__schema` field on the `query` root operation type
+- Introspection is often disabled in production environments
 
-This has just scratched the surface of the introspection system; we can
-query for enum values, what interfaces a type implements, and more. We
-can even introspect on the introspection system itself. The specification goes
-into more detail about this topic in the "Introspection" section, and the [introspection](https://github.com/graphql/graphql-js/blob/main/src/type/introspection.ts)
-file in GraphQL.js contains code implementing a specification-compliant GraphQL
-query introspection system.
+Now that you've explored the GraphQL type system, how to query data from an API, and what the lifecycle of a request looks like, head over to the [Best Practices](/learn/best-practices/) section to learn more about running GraphQL in production.
\ No newline at end of file
diff --git a/src/pages/learn/pagination.mdx b/src/pages/learn/pagination.mdx
index 1c82275943..da8427d50a 100644
--- a/src/pages/learn/pagination.mdx
+++ b/src/pages/learn/pagination.mdx
@@ -1,16 +1,16 @@
 # Pagination
 
-> Different pagination models enable different client capabilities
+<p className="learn-subtitle">Traverse lists of objects with a consistent field pagination model</p>
 
-A common use case in GraphQL is traversing the relationship between sets of objects. There are a number of different ways that these relationships can be exposed in GraphQL, giving a varying set of capabilities to the client developer.
+A common use case in GraphQL is traversing the relationship between sets of objects. There are different ways that these relationships can be exposed in GraphQL, giving a varying set of capabilities to the client developer. On this page, we'll explore how fields may be paginated using a cursor-based connection model.
 
 ## Plurals
 
-The simplest way to expose a connection between objects is with a field that returns a plural type. For example, if we wanted to get a list of R2-D2's friends, we could just ask for all of them:
+The simplest way to expose a connection between objects is with a field that returns a plural [List type](/learn/schema/#list). For example, if we wanted to get a list of R2-D2's friends, we could just ask for all of them:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   hero {
     name
     friends {
@@ -22,10 +22,10 @@ The simplest way to expose a connection between objects is with a field that ret
 
 ## Slicing
 
-Quickly, though, we realize that there are additional behaviors a client might want. A client might want to be able to specify how many friends they want to fetch; maybe they only want the first two. So we'd want to expose something like:
+Quickly, though, we realize that there are additional behaviors a client might want. A client might want to be able to specify how many friends they want to fetch—maybe they only want the first two. So we'd want to expose something like this:
 
 ```graphql
-{
+query {
   hero {
     name
     friends(first: 2) {
@@ -37,20 +37,22 @@ Quickly, though, we realize that there are additional behaviors a client might w
 
 But if we just fetched the first two, we might want to paginate through the list as well; once the client fetches the first two friends, they might want to send a second request to ask for the next two friends. How can we enable that behavior?
 
-## Pagination and Edges
+## Pagination and edges
 
-There are a number of ways we could do pagination:
+There are several ways we could do pagination:
 
 - We could do something like `friends(first:2 offset:2)` to ask for the next two in the list.
 - We could do something like `friends(first:2 after:$friendId)`, to ask for the next two after the last friend we fetched.
 - We could do something like `friends(first:2 after:$friendCursor)`, where we get a cursor from the last item and use that to paginate.
 
-In general, we've found that **cursor-based pagination** is the most powerful of those designed. Especially if the cursors are opaque, either offset or ID-based pagination can be implemented using cursor-based pagination (by making the cursor the offset or the ID), and using cursors gives additional flexibility if the pagination model changes in the future. As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
+The approach described in the first bullet is classic _offset-based pagination_. However, this style of pagination can have performance and security downsides, especially for larger data sets. Additionally, if new records are added to the database after the user has made a request for a page of results, then offset calculations for subsequent pages may become ambiguous.
 
-That leads us to a problem; though; how do we get the cursor from the object? We wouldn't want cursor to live on the `User` type; it's a property of the connection, not of the object. So we might want to introduce a new layer of indirection; our `friends` field should give us a list of edges, and an edge has both a cursor and the underlying node:
+In general, we've found that _cursor-based pagination_ is the most powerful of those designed. Especially if the cursors are opaque, either offset or ID-based pagination can be implemented using cursor-based pagination (by making the cursor the offset or the ID), and using cursors gives additional flexibility if the pagination model changes in the future. As a reminder that the cursors are opaque and their format should not be relied upon, we suggest base64 encoding them.
+
+But that leads us to a problem—how do we get the cursor from the object? We wouldn't want the cursor to live on the `User` type; it's a property of the connection, not of the object. So we might want to introduce a new layer of indirection; our `friends` field should give us a list of edges, and an edge has both a cursor and the underlying node:
 
 ```graphql
-{
+query {
   hero {
     name
     friends(first: 2) {
@@ -67,14 +69,14 @@ That leads us to a problem; though; how do we get the cursor from the object? We
 
 The concept of an edge also proves useful if there is information that is specific to the edge, rather than to one of the objects. For example, if we wanted to expose "friendship time" in the API, having it live on the edge is a natural place to put it.
 
-## End-of-list, counts, and Connections
+## End-of-list, counts, and connections
 
-Now we have the ability to paginate through the connection using cursors, but how do we know when we reach the end of the connection? We have to keep querying until we get an empty list back, but we'd really like for the connection to tell us when we've reached the end so we don't need that additional request. Similarly, what if we want to know additional information about the connection itself; for example, how many total friends does R2-D2 have?
+Now we can paginate through the connection using cursors, but how do we know when we reach the end of the connection? We have to keep querying until we get an empty list back, but we'd like for the connection to tell us when we've reached the end so we don't need that additional request. Similarly, what if we want additional information about the connection itself, for example, how many friends does R2-D2 have in total?
 
-To solve both of these problems, our `friends` field can return a connection object. The connection object will then have a field for the edges, as well as other information (like total count and information about whether a next page exists). So our final query might look more like:
+To solve both of these problems, our `friends` field can return a connection object. The connection object will be an Object type that has a field for the edges, as well as other information (like total count and information about whether a next page exists). So our final query might look more like this:
 
 ```graphql
-{
+query {
   hero {
     name
     friends(first: 2) {
@@ -96,20 +98,50 @@ To solve both of these problems, our `friends` field can return a connection obj
 
 Note that we also might include `endCursor` and `startCursor` in this `PageInfo` object. This way, if we don't need any of the additional information that the edge contains, we don't need to query for the edges at all, since we got the cursors needed for pagination from `pageInfo`. This leads to a potential usability improvement for connections; instead of just exposing the `edges` list, we could also expose a dedicated list of just the nodes, to avoid a layer of indirection.
 
-## Complete Connection Model
+## Complete connection model
 
-Clearly, this is more complex than our original design of just having a plural! But by adopting this design, we've unlocked a number of capabilities for the client:
+Clearly, this is more complex than our original design of just having a plural! But by adopting this design, we've unlocked several capabilities for the client:
 
 - The ability to paginate through the list.
 - The ability to ask for information about the connection itself, like `totalCount` or `pageInfo`.
 - The ability to ask for information about the edge itself, like `cursor` or `friendshipTime`.
 - The ability to change how our backend does pagination, since the user just uses opaque cursors.
 
-To see this in action, there's an additional field in the example schema, called `friendsConnection`, that exposes all of these concepts. You can check it out in the example query. Try removing the `after` parameter to `friendsConnection` to see how the pagination will be affected. Also, try replacing the `edges` field with the helper `friends` field on the connection, which lets you get directly to the list of friends without the additional edge layer of indirection, when that's appropriate for clients.
+To see this in action, there's an additional field in the example schema, called `friendsConnection`, that exposes all of these concepts:
+
+```graphql
+interface Character {
+  id: ID!
+  name: String!
+  friends: [Character]
+  friendsConnection(first: Int, after: ID): FriendsConnection!
+  appearsIn: [Episode]!
+}
+
+type FriendsConnection {
+  totalCount: Int
+  edges: [FriendsEdge]
+  friends: [Character]
+  pageInfo: PageInfo!
+}
+
+type FriendsEdge {
+  cursor: ID!
+  node: Character
+}
+
+type PageInfo {
+  startCursor: ID
+  endCursor: ID
+  hasNextPage: Boolean!
+}
+```
+
+You can try it out in the example query. Try removing the `after` argument for the `friendsConnection` field to see how the pagination will be affected. Also, try replacing the `edges` field with the helper `friends` field on the connection, which lets you get directly to the list of friends without the additional edge layer of indirection, when appropriate for clients:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   hero {
     name
     friendsConnection(first: 2, after: "Y3Vyc29yMQ==") {
@@ -129,6 +161,14 @@ To see this in action, there's an additional field in the example schema, called
 }
 ```
 
-## Connection Specification
+## Connection specification
+
+To ensure a consistent implementation of this pattern, the Relay project has a formal [specification](https://relay.dev/graphql/connections.htm) you can follow for building GraphQL APIs that use a cursor-based connection pattern - whether or not use you Relay.
+
+## Recap
+
+To recap these recommendations for paginating fields in a GraphQL schema:
 
-To ensure a consistent implementation of this pattern, the Relay project has a formal [specification](https://facebook.github.io/relay/graphql/connections.htm) you can follow for building GraphQL APIs which use a cursor based connection pattern.
+- List fields that may return a lot of data should be paginated
+- Cursor-based pagination provides a stable pagination model for fields in a GraphQL schema
+- The cursor connection specification from the Relay project provides a consistent pattern for paginating the fields in a GraphQL schema
diff --git a/src/pages/learn/response.mdx b/src/pages/learn/response.mdx
new file mode 100644
index 0000000000..d93c1fb855
--- /dev/null
+++ b/src/pages/learn/response.mdx
@@ -0,0 +1,122 @@
+import { Callout } from "nextra/components"
+
+# Response
+
+<p className="learn-subtitle">Learn how GraphQL returns data to clients</p>
+
+After a GraphQL document has been [validated](/learn/validation/) and [executed](/learn/execution/), the server will return a [response](https://spec.graphql.org/draft/#sec-Response) to the requesting client. One of GraphQL's strengths is that the server response reflects the shape of the client's original request, but a response may also contain helpful information if something unexpected happened before or during the execution of an operation. On this page, we'll take a deeper exploration of this final phase in the lifecycle of a GraphQL request.
+
+## Data
+
+As we have seen in the examples throughout this guide, when a GraphQL request is executed the response is returned on a top-level `data` key. For example:
+
+```graphql
+# { "graphiql": true }
+query {
+  human(id: 1002) {
+    name
+    appearsIn
+    starships {
+      name
+    }
+  }
+}
+```
+
+The inclusion of the `data` key isn't an arbitrary decision made by the underlying GraphQL implementation—it's described by the [GraphQL specification](https://spec.graphql.org/draft/#sec-Data). Under this key, you will find the result of the execution of the requested operation, which may include partial data for the requested fields if errors were raised during the execution of some field resolvers.
+
+One thing that the GraphQL specification doesn't require is a specific serialization format for the response. That said, responses are typically formatted as JSON, as in the example above.
+
+Additionally, the GraphQL specification doesn't require the use of a particular transport protocol for requests either, although it is [common for HTTP to be used](/learn/serving-over-http/) for stateless query and mutations operations. Long-lived, stateful subscription operations are often supported by WebSockets or server-sent events instead.
+
+<Callout type="info">
+There is [a draft GraphQL over HTTP specification](https://graphql.github.io/graphql-over-http/draft/) available with further guidelines for using HTTP with GraphQL clients and servers.
+</Callout>
+
+## Errors
+
+In addition to the `data` key, the GraphQL specification outlines how [errors](https://spec.graphql.org/draft/#sec-Errors) should be formatted in the response. Whether the GraphQL implementation provides partial data with the error information in the response will depend on the type of error that was raised. Let's look at the different kinds of errors that can occur during the lifecycle of a GraphQL request.
+
+### Request errors
+
+Request errors typically occur because the client made a mistake. For example, there may be a _syntax error_ in the document, such as a missing bracket or the use of an unknown root operation type keyword:
+
+```graphql
+# { "graphiql": true }
+operation { 
+  updateHumanName(id: "1000", name: "Luke Starkiller" ) {
+    id
+    name
+  }
+}
+```
+
+The `message` key inside the `errors` object provides some helpful information for the developer to understand what kind of error was raised, and the `locations` key, if present, indicates where the error occurred in the document.
+
+Sometimes, a GraphQL request may be syntactically correct, but when the server parses and [validates](/learn/validation/) the document against the schema, it finds an issue with part of the operation and raises a _validation error_.
+
+For example, the client may request a field that does not exist on the `Starship` type:
+
+```graphql
+# { "graphiql": true }
+query {
+  starship(id: 3000) {
+    width
+  }
+}
+```
+
+Validation errors also occur when clients specify incorrect variable types for their corresponding field arguments:
+
+```graphql
+# { "graphiql": true, "variables": { "ep": "JEDI" } }
+query HeroForEpisode($ep: String!) {
+  hero(episode: $ep) {
+    name
+  }
+}
+```
+
+In the previous examples, we can see that when a request error occurs the `data` key will not be included because the server returns an error response to the client before the field resolvers are executed.
+
+### Field errors
+
+Field errors are raised if something unexpected happens during execution. For example, a resolver may raise an error directly, or may return invalid data such as a null value for a field that has a Non-Null output type.
+
+In these cases, GraphQL will attempt to continue executing the other fields and return a partial response, with the `data` key appearing alongside the `errors` key.
+
+Let's look at an example:
+
+```graphql
+# { "graphiql": true }
+mutation {
+  firstShip: deleteStarship(id: "3001")
+  secondShip: deleteStarship(id: "3010")
+}
+```
+
+The mutation above attempts to delete two starships in a single operation, but no starship exists with an ID of `3010` so the server throws an error. In the response, we can see information about the error that occurred for the field that was aliased as `secondShip`. Under the `data` key, we also see that the ID of the first ship was returned to indicate successful deletion, while the second ship produced a null result due to the error raised in its resolver function.
+
+### Network errors
+
+As with network calls to any type of API, network errors that are not specific to GraphQL may happen at any point during a request. These kinds of errors will block communication between the client and server before the request is complete, such as an SSL error or a connection timeout. Depending on the GraphQL server and client libraries that you choose, there may be features built into them that support special network error handling such as retries for failed operations.
+
+## Extensions
+
+The final top-level key allowed by the GraphQL specification in a response is the `extentions` key. This key is reserved for GraphQL implementations to provide additional information about the response and though it must be an object if present, there are no other restrictions on what it may contain.
+
+For example, some GraphQL servers may include telemetry data or information about rate limit consumption under this key. Note that what data is available in `extensions` and whether this data is available in production or development environments will depend entirely on the specific GraphQL implementation.
+
+## Next steps
+
+To recap what we've learned about GraphQL response formats:
+
+- The GraphQL specification allows three top-level keys in a response: `data`, `errors`, and `extensions`
+- At least one of `data` or `errors` will be present on the response (when it contains both it is a "partial response")
+- The `data` key contains the result of the executed operation
+- Information about raised errors is included in the `errors` key of the response
+- Request errors (such as syntax or validation errors) are raised before execution begins so `data` won't be included in the response
+- When a field error occurs during execution, there will be a description of the issue in the `errors` key and there may be partial data included with the `data` key
+- GraphQL implementations may include additional arbitrary information about the response in the `extensions` key
+
+Now that you understand the different phases of a GraphQL request and how responses are provided to clients, head over to the [Introspection](/learn/introspection) page to learn about how a GraphQL server can query information about its own schema.
\ No newline at end of file
diff --git a/src/pages/learn/schema.mdx b/src/pages/learn/schema.mdx
index b87c116561..b10ff9ad36 100644
--- a/src/pages/learn/schema.mdx
+++ b/src/pages/learn/schema.mdx
@@ -1,6 +1,12 @@
+import { Callout } from "nextra/components"
+
 # Schemas and Types
 
-On this page, you'll learn all you need to know about the GraphQL type system and how it describes what data can be queried. Since GraphQL can be used with any backend framework or programming language, we'll stay away from implementation-specific details and talk only about the concepts.
+<p className="learn-subtitle">Learn about the different elements of the GraphQL type system</p>
+
+The GraphQL [type system](https://spec.graphql.org/draft/#sec-Type-System) describes what data can be queried from the API. The collection of those capabilities is referred to as the service's _schema_ and clients can use that schema to send queries to the API that return predictable results.
+
+On this page, we'll explore GraphQL's [six kinds of named type definitions](https://spec.graphql.org/draft/#sec-Types) as well as other features of the type system to learn how they may be used to describe your data and the relationships between them. Since GraphQL can be used with any backend framework or programming language, we'll avoid implementation-specific details and talk only about the concepts.
 
 ## Type system
 
@@ -20,17 +26,24 @@ If you've seen a GraphQL query before, you know that the GraphQL query language
 2. We select the `hero` field on that
 3. For the object returned by `hero`, we select the `name` and `appearsIn` fields
 
-Because the shape of a GraphQL query closely matches the result, you can predict what the query will return without knowing that much about the server. But it's useful to have an exact description of the data we can ask for - what fields can we select? What kinds of objects might they return? What fields are available on those sub-objects? That's where the schema comes in.
+Because the shape of a GraphQL query closely matches the result, we can predict what the query will return without knowing that much about the server. But it's useful to have an exact description of the data we can request. For example, what fields can we select? What kinds of objects might they return? What fields are available on those sub-objects?
 
-Every GraphQL service defines a set of types which completely describe the set of possible data you can query on that service. Then, when queries come in, they are validated and executed against that schema.
+That's where the schema comes in. Every GraphQL service defines a set of types that completely describe the set of possible data we can query on that service. Then, when requests come in, they are validated and executed against that schema.
 
 ## Type language
 
-GraphQL services can be written in any language. Since we can't rely on a specific programming language syntax, like JavaScript, to talk about GraphQL schemas, we'll define our own simple language. We'll use the "GraphQL schema language" - it's similar to the query language, and allows us to talk about GraphQL schemas in a language-agnostic way.
+GraphQL services can be written in any language and there are many different approaches you can take when defining the types in a schema:
+
+- Some libraries have you construct the schema types, fields, and resolver functions together using the same programming language that was used to write the GraphQL implementation.
+- Some libraries allow you to define types and fields more ergonomically using what's commonly called the schema definition language (or SDL) and then write the resolver functions for the corresponding fields separately.
+- Some libraries allow you to write and annotate the resolver functions, and then infer the schema from that.
+- Some libraries may even infer both the types and resolver functions for you, based on some underlying data source(s).
+
+Since we can't rely on a specific programming language to discuss GraphQL schemas in this guide, we'll use SDL because it's similar to the query language that we've seen so far and allows us to talk about GraphQL schemas in a language-agnostic way.
 
 ## Object types and fields
 
-The most basic components of a GraphQL schema are object types, which just represent a kind of object you can fetch from your service, and what fields it has. In the GraphQL schema language, we might represent it like this:
+The most basic components of a GraphQL schema are [Object types](https://spec.graphql.org/draft/#sec-Objects), which just represent a kind of object you can fetch from your service, and what fields it has. In SDL, we represent it like this:
 
 ```graphql
 type Character {
@@ -39,19 +52,19 @@ type Character {
 }
 ```
 
-The language is pretty readable, but let's go over it so that we can have a shared vocabulary:
+The language is readable, but let's go over it so that we can have a shared vocabulary:
 
-- `Character` is a _GraphQL Object Type_, meaning it's a type with some fields. Most of the types in your schema will be object types.
-- `name` and `appearsIn` are _fields_ on the `Character` type. That means that `name` and `appearsIn` are the only fields that can appear in any part of a GraphQL query that operates on the `Character` type.
-- `String` is one of the built-in _scalar_ types - these are types that resolve to a single scalar object, and can't have sub-selections in the query. We'll go over scalar types more later.
-- `String!` means that the field is _non-nullable_, meaning that the GraphQL service promises to always give you a value when you query this field. In the type language, we'll represent those with an exclamation mark.
-- `[Episode!]!` represents an _array_ of `Episode` objects. Since it is also _non-nullable_, you can always expect an array (with zero or more items) when you query the `appearsIn` field. And since `Episode!` is also _non-nullable_, you can always expect every item of the array to be an `Episode` object.
+- `Character` is a [GraphQL Object type](#object-types-and-fields), meaning it's a type with some fields. Most of the types in your schema will be Object types.
+- `name` and `appearsIn` are [fields](#object-types-and-fields) on the `Character` type. That means that `name` and `appearsIn` are the only fields that can appear in any part of a GraphQL query that operates on the `Character` type.
+- `String` is one of the built-in [Scalar types](#scalar-types). These are types that resolve to a single scalar value and can't have sub-selections in the query. We'll go over Scalar types more later.
+- `String!` means that the field is a [Non-Null type](#non-null), meaning the GraphQL service promises to give you a value whenever you query this field. In SDL, we represent those with an exclamation mark.
+- `[Episode!]!` represents an [List type](#list) of `Episode` objects. When a List is Non-Null, you can always expect an array (with zero or more items) when you query the `appearsIn` field. In this case, since `Episode!` is also Non-Null within the list, you can always expect every item in the array to be an `Episode` object.
 
-Now you know what a GraphQL object type looks like, and how to read the basics of the GraphQL type language.
+Now you know what a GraphQL Object type looks like and how to read the basics of SDL.
 
-## Arguments
+### Arguments
 
-Every field on a GraphQL object type can have zero or more arguments, for example the `length` field below:
+Every field on a GraphQL Object type can have zero or more [arguments](https://spec.graphql.org/draft/#sec-Field-Arguments), for example, the `length` field below:
 
 ```graphql
 type Starship {
@@ -61,53 +74,50 @@ type Starship {
 }
 ```
 
-All arguments are named. Unlike languages like JavaScript and Python where functions take a list of ordered arguments, all arguments in GraphQL are passed by name specifically. In this case, the `length` field has one defined argument, `unit`.
+All arguments are named. Unlike languages such as JavaScript and Python where functions take a list of ordered arguments, all arguments in GraphQL are passed by name specifically. In this case, the `length` field has one defined argument called `unit`.
 
-Arguments can be either required or optional. When an argument is optional, we can define a _default value_ - if the `unit` argument is not passed, it will be set to `METER` by default.
+Arguments can be either required or optional. When an argument is optional, we can define a _default value_. If the `unit` argument is not passed, then it will be set to `METER` by default.
 
-## The Query and Mutation types
+### The Query, Mutation, and Subscription types
 
-Most types in your schema will just be normal object types, but there are two types that are special within a schema:
-
-```graphql
-schema {
-  query: Query
-  mutation: Mutation
-}
-```
-
-Every GraphQL service has a `query` type and may or may not have a `mutation` type. These types are the same as a regular object type, but they are special because they define the _entry point_ of every GraphQL query. So if you see a query that looks like:
+Every GraphQL schema must support `query` operations. The _entry point_ for this [root operation type](https://spec.graphql.org/draft/#sec-Root-Operation-Types) is a regular Object type called `Query` by default. So if you see a query that looks like this:
 
 ```graphql
 # { "graphiql": true }
-query {
-  hero {
-    name
-  }
+{
   droid(id: "2000") {
     name
   }
 }
 ```
 
-That means that the GraphQL service needs to have a `Query` type with `hero` and `droid` fields:
+That means that the GraphQL service needs to have a `Query` type with a `droid` field:
 
 ```graphql
 type Query {
-  hero(episode: Episode): Character
   droid(id: ID!): Droid
 }
 ```
 
-Mutations work in a similar way - you define fields on the `Mutation` type, and those are available as the root mutation fields you can call in your query.
+Schemas may also support `mutation` and `subscription` operations by adding additional `Mutation` and `Subscription` types and then defining fields on the corresponding root operation types.
+
+It's important to remember that other than the special status of being entry points into the schema, the `Query`, `Mutation`, and `Subscription` types are the same as any other GraphQL Object type, and their fields work exactly the same way.
+
+You can name your root operation types differently too; if you choose to do so then you will need to inform GraphQL of the new names using the `schema` keyword:
 
-It's important to remember that other than the special status of being the "entry point" into the schema, the `Query` and `Mutation` types are the same as any other GraphQL object type, and their fields work exactly the same way.
+```graphql
+schema {
+  query: MyQueryType
+  mutation: MyMutationType
+  subscription: MySubscriptionType
+}
+```
 
 ## Scalar types
 
-A GraphQL object type has a name and fields, but at some point those fields have to resolve to some concrete data. That's where the scalar types come in: they represent the leaves of the query.
+A GraphQL Object type has a name and fields, but at some point, those fields must resolve to some concrete data. That's where the [Scalar types](https://spec.graphql.org/draft/#sec-Scalars) come in: they represent the leaf values of the query.
 
-In the following query, the `name` and `appearsIn` fields will resolve to scalar types:
+In the following query, the `name` and `appearsIn` fields will resolve to Scalar types:
 
 ```graphql
 # { "graphiql": true }
@@ -119,17 +129,17 @@ In the following query, the `name` and `appearsIn` fields will resolve to scalar
 }
 ```
 
-We know this because those fields don't have any sub-fields - they are the leaves of the query.
+We know this because those fields don't have any sub-fields—they are the leaves of the query.
 
-GraphQL comes with a set of default scalar types out of the box:
+GraphQL comes with a set of [default Scalar types](https://spec.graphql.org/draft/#sec-Scalars.Built-in-Scalars) out of the box:
 
 - `Int`: A signed 32‐bit integer.
 - `Float`: A signed double-precision floating-point value.
 - `String`: A UTF‐8 character sequence.
 - `Boolean`: `true` or `false`.
-- `ID`: The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, defining it as an `ID` signifies that it is not intended to be human‐readable.
+- `ID`: A unique identifier, often used to refetch an object or as the key for a cache. The `ID` type is serialized in the same way as a `String`; however, defining it as an `ID` signifies that it is not intended to be human‐readable.
 
-In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a `Date` type:
+In most GraphQL service implementations, there is also a way to specify custom Scalar types. For example, we could define a `Date` type:
 
 ```graphql
 scalar Date
@@ -137,14 +147,14 @@ scalar Date
 
 Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the `Date` type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.
 
-## Enumeration types
+## Enum types
 
-Also called _Enums_, enumeration types are a special kind of scalar that is restricted to a particular set of allowed values. This allows you to:
+[Enum types](https://spec.graphql.org/draft/#sec-Enums), also known as enumeration types, are a special kind of scalar that is restricted to a particular set of allowed values. This allows you to:
 
 1. Validate that any arguments of this type are one of the allowed values
 2. Communicate through the type system that a field will always be one of a finite set of values
 
-Here's what an enum definition might look like in the GraphQL schema language:
+Here's what an Enum type definition looks like in SDL:
 
 ```graphql
 enum Episode {
@@ -156,35 +166,49 @@ enum Episode {
 
 This means that wherever we use the type `Episode` in our schema, we expect it to be exactly one of `NEWHOPE`, `EMPIRE`, or `JEDI`.
 
-Note that GraphQL service implementations in various languages will have their own language-specific way to deal with enums. In languages that support enums as a first-class citizen, the implementation might take advantage of that; in a language like JavaScript with no enum support, these values might be internally mapped to a set of integers. However, these details don't leak out to the client, which can operate entirely in terms of the string names of the enum values.
+<Callout type="info">GraphQL service implementations in various languages will have a language-specific way of dealing with Enum types. In languages that support enums as a first-class citizen, the implementation might take advantage of that; in a language like JavaScript with no enum support, these values might be internally mapped to a set of integers. However, these details don't leak out to the client, which can operate entirely in terms of the string names of the Enum type's values.</Callout>
+
+## Type modifiers
 
-## Lists and Non-Null
+Types are assumed to be nullable and singular by default in GraphQL. However, when you use these named types in a schema (or in [query variable declarations](/learn/queries/#variables)) you can apply additional _type modifiers_ that will affect the meaning of those values.
 
-Object types, scalars, and enums are the only kinds of types you can define in GraphQL. But when you use the types in other parts of the schema, or in your query variable declarations, you can apply additional _type modifiers_ that affect validation of those values. Let's look at an example:
+As we saw with the Object type example above, GraphQL supports two type modifiers—the [List](https://spec.graphql.org/draft/#sec-List) and [Non-Null](https://spec.graphql.org/draft/#sec-Non-Null) types—and they can be used individually or in combination with each other.
+
+### Non-Null
+
+Let's look at an example:
 
 ```graphql
 type Character {
   name: String!
-  appearsIn: [Episode]!
 }
 ```
 
-Here, we're using a `String` type and marking it as _Non-Null_ by adding an exclamation mark, `!` after the type name. This means that our server always expects to return a non-null value for this field, and if it ends up getting a null value that will actually trigger a GraphQL execution error, letting the client know that something has gone wrong.
+Here, we're using a `String` type and marking it as a Non-Null type by adding an exclamation mark (`!`) after the type name. This means that our server always expects to return a non-null value for this field, and if the resolver produces a null value, then that will trigger a GraphQL execution error, letting the client know that something has gone wrong.
 
-The Non-Null type modifier can also be used when defining arguments for a field, which will cause the GraphQL server to return a validation error if a null value is passed as that argument, whether in the GraphQL string or in the variables.
+As we saw in an example above, the Non-Null type modifier can also be used when defining arguments for a field, which will cause the GraphQL server to return a validation error if a null value is passed as that argument:
 
 ```graphql
-# { "graphiql": true, "variables": { "id": null } }
-query DroidById($id: ID!) {
-  droid(id: $id) {
+# { "graphiql": true }
+{
+  droid(id: null) {
     name
   }
 }
 ```
 
-Lists work in a similar way: We can use a type modifier to mark a type as a `List`, which indicates that this field will return an array of that type. In the schema language, this is denoted by wrapping the type in square brackets, `[` and `]`. It works the same for arguments, where the validation step will expect an array for that value.
+### List
 
-The Non-Null and List modifiers can be combined. For example, you can have a List of Non-Null Strings:
+Lists work in a similar way. We can use a type modifier to mark a type as a List type, which indicates that this field will return an array of that type. In SDL, this is denoted by wrapping the type in square brackets, `[` and `]`. It works the same for arguments, where the validation step will expect an array for that value. Here's an example:
+
+```graphql
+type Character {
+  name: String!
+  appearsIn: [Episode]!
+}
+```
+
+As we see above, the Non-Null and List modifiers can be combined. For example, you can have a List of Non-Null `String` types:
 
 ```graphql
 myField: [String!]
@@ -199,7 +223,7 @@ myField: ["a", "b"] // valid
 myField: ["a", null, "b"] // error
 ```
 
-Now, let's say we defined a Non-Null List of Strings:
+Now, let's say we defined a Non-Null List of `String` types:
 
 ```graphql
 myField: [String]!
@@ -214,13 +238,30 @@ myField: ["a", "b"] // valid
 myField: ["a", null, "b"] // valid
 ```
 
+Lastly, you can also have a Non-Null List of Non-Null `String` types:
+
+```graphql
+myField: [String!]!
+```
+
+This means that the list cannot be null and it cannot contain null values:
+
+```js
+myField: null // error
+myField: [] // valid
+myField: ["a", "b"] // valid
+myField: ["a", null, "b"] // error
+```
+
 You can arbitrarily nest any number of Non-Null and List modifiers, according to your needs.
 
-## Interfaces
+<Callout type="info">In GraphQL, there is no way to define a type so that the field's data will only be considered valid if a non-empty list is provided. In other words, `[]` would still be a valid response for a Non-Null List of a Non-Null type.</Callout>
 
-Like many type systems, GraphQL supports interfaces. An _Interface_ is an abstract type that includes a certain set of fields that a type must include to implement the interface.
+## Interface types
 
-For example, you could have an interface `Character` that represents any character in the Star Wars trilogy:
+Like many type systems, GraphQL supports _abstract types_. The first of these types that we'll explore is an [Interface type](https://spec.graphql.org/draft/#sec-Interfaces), which defines a certain set of fields that a concrete Object type or other Interface type must also include to implement it.
+
+For example, you could have an `Character` Interface type that represents any character in the Star Wars trilogy:
 
 ```graphql
 interface Character {
@@ -231,7 +272,7 @@ interface Character {
 }
 ```
 
-This means that any type that _implements_ `Character` needs to have these exact fields, with these arguments and return types.
+This means that any type that _implements_ `Character` needs to have these exact fields as well as the same arguments and return types.
 
 For example, here are some types that might implement `Character`:
 
@@ -254,30 +295,28 @@ type Droid implements Character {
 }
 ```
 
-You can see that both of these types have all of the fields from the `Character` interface, but also bring in extra fields, `totalCredits`, `starships` and `primaryFunction`, that are specific to that particular type of character.
-
-Interfaces are useful when you want to return an object or set of objects, but those might be of several different types.
+You can see that both of these types have all of the fields from the `Character` Interface type, but also bring in extra fields—`totalCredits`, `starships` and `primaryFunction`—that are specific to that particular type of character.
 
-For example, note that the following query produces an error:
+Interface types are useful when you want to return an object or set of objects, but those might be of several different types. For example, note that the following query produces an error:
 
 ```graphql
-# { "graphiql": true, "variables": { "ep": "JEDI" } }
-query HeroForEpisode($ep: Episode!) {
-  hero(episode: $ep) {
+# { "graphiql": true }
+{
+  hero(episode: JEDI) {
     name
     primaryFunction
   }
 }
 ```
 
-The `hero` field returns the type `Character`, which means it might be either a `Human` or a `Droid` depending on the `episode` argument. In the query above, you can only ask for fields that exist on the `Character` interface, which doesn't include `primaryFunction`.
+The `hero` field returns the type `Character`, which means it might be either a `Human` or a `Droid` depending on the `episode` argument. In the query above, you can only ask for fields that exist on the `Character` Interface type, which doesn't include `primaryFunction`.
 
-To ask for a field on a specific object type, you need to use an inline fragment:
+To ask for a field on a specific Object type, you need to use an [inline fragment](/learn/queries/#inline-fragments):
 
 ```graphql
-# { "graphiql": true, "variables": { "ep": "JEDI" } }
-query HeroForEpisode($ep: Episode!) {
-  hero(episode: $ep) {
+# { "graphiql": true }
+{
+  hero(episode: JEDI) {
     name
     ... on Droid {
       primaryFunction
@@ -286,19 +325,38 @@ query HeroForEpisode($ep: Episode!) {
 }
 ```
 
-Learn more about this in the [inline fragments](/learn/queries/#inline-fragments) section in the query guide.
+Interface types may also implement other Interface types:
+
+```graphql
+interface Node {
+  id: ID!
+}
+
+interface Character implements Node {
+  id: ID!
+  name: String!
+  friends: [Character]
+  appearsIn: [Episode]!
+}
+```
+
+Note that Interface types may not implement themselves or contain any cyclic references to each other.
+
+<Callout type="info">While types may share common fields in a GraphQL API, that may not always warrant the use of an Interface type to enforce that those fields remain consistently named. Interface types are a powerful way to indicate shared behavior across the types that implement them. When used, they should be semantically meaningful to client developers, just like `Character` is a useful abstraction for humans and droids.</Callout>
 
 ## Union types
 
-Union types share similarities with interfaces; however, they lack the ability to define any shared fields among the constituent types.
+GraphQL supports a second abstract type called a [Union type](https://spec.graphql.org/draft/#sec-Unions). Union types share similarities with Interface types, but they cannot define any shared fields among the constituent types.
+
+A Union type is defined by indicating its member Object types:
 
 ```graphql
 union SearchResult = Human | Droid | Starship
 ```
 
-Wherever we return a `SearchResult` type in our schema, we might get a `Human`, a `Droid`, or a `Starship`. Note that members of a union type need to be concrete object types; you can't create a union type out of interfaces or other unions.
+Wherever we return a `SearchResult` type in our schema, we might get a `Human`, a `Droid`, or a `Starship`. Note that members of a Union type need to be concrete Object types; you can't define one using Interface types or other Union types as members.
 
-In this case, if you query a field that returns the `SearchResult` union type, you need to use an inline fragment to be able to query any fields at all:
+In this case, if you query a field that returns the `SearchResult` Union type, you need to use an [inline fragment](/learn/queries/#inline-fragments) to be able to query any fields that are defined on the member Object types:
 
 ```graphql
 # { "graphiql": true}
@@ -321,11 +379,12 @@ In this case, if you query a field that returns the `SearchResult` union type, y
 }
 ```
 
-The `__typename` field resolves to a `String` which lets you differentiate different data types from each other on the client.
+The `__typename` field is a special _meta-field_ that automatically exists on every Object type and resolves to the name of that type, providing a way to differentiate between data types on the client.
 
-Also, in this case, since `Human` and `Droid` share a common interface (`Character`), you can query their common fields in one place rather than having to repeat the same fields across multiple types:
+Also, in this case, since `Human` and `Droid` share a common interface (`Character`), you can query their common fields in one place and still get the same result:
 
 ```graphql
+# { "graphiql": true}
 {
   search(text: "an") {
     __typename
@@ -348,27 +407,160 @@ Also, in this case, since `Human` and `Droid` share a common interface (`Charact
 
 Note that `name` is still specified on `Starship` because otherwise it wouldn't show up in the results given that `Starship` is not a `Character`!
 
-## Input types
+## Input Object types
+
+Most of the examples we've covered on this page demonstrate how Object, Scalar, Enum, Interface, and Union types may be used as _output types_ for the fields in a schema. But we have also seen that field arguments must specify their _input types_. 
+
+So far, we've only talked about using scalar values (like Enums or String types) as an input type for a field argument. However, you can also pass complex objects as arguments using an [Input Object type](https://spec.graphql.org/draft/#sec-Input-Objects), which is the last kind of named types in GraphQL that we'll explore.
 
-So far, we've only talked about passing scalar values, like enums or strings, as arguments into a field. But you can also easily pass complex objects. This is particularly valuable in the case of mutations, where you might want to pass in a whole object to be created. In the GraphQL schema language, input types look exactly the same as regular object types, but with the keyword `input` instead of `type`:
+This is particularly valuable in the case of [mutations](/learn/queries/#mutations), where you might want to pass in a whole object to be created. In SDL, Input Object types look similar to regular Object types, but with the keyword `input` instead of `type`:
 
 ```graphql
 input ReviewInput {
   stars: Int!
   commentary: String
 }
+
+type Mutation {
+  createReview(episode: Episode, review: ReviewInput!): Review
+}
 ```
 
-Here is how you could use the input object type in a mutation:
+Here is how you could use the Input Object type in a mutation:
 
 ```graphql
-# { "graphiql": true, "variables": { "ep": "JEDI", "review": { "stars": 5, "commentary": "This is a great movie!" } } }
-mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {
-  createReview(episode: $ep, review: $review) {
+# { "graphiql": true }
+mutation {
+  createReview(
+    episode: JEDI, 
+    review: {
+      stars: 5
+      commentary: "This is a great movie!"
+    }
+  ) {
     stars
     commentary
   }
 }
 ```
 
-The fields on an input object type can themselves refer to input object types, but you can't mix input and output types in your schema. Input object types also can't have arguments on their fields.
+The fields on an Input Object type can refer to other Input Object types, but you can't mix input and output types in your schema. Input Object types also can't have arguments on their fields.
+
+## Directives
+
+In certain instances where field arguments are insufficient or certain common behaviors must be replicated in multiple locations, [directives](https://spec.graphql.org/draft/#sec-Type-System.Directives) allow us to modify parts of a GraphQL schema or operation by using an `@` character followed by the directive's name.
+
+_Type system directives_ allow us to annotate the types, fields, and arguments in a schema so that they may be validated or executed differently.
+
+<Callout type="info">
+Directives may also be defined for use in GraphQL operations as _executable directives_. [Read more about executable directives on the Queries page.](/learn/queries/#directives)
+</Callout>
+
+The GraphQL specification defines several [built-in directives](https://spec.graphql.org/draft/#sec-Type-System.Directives.Built-in-Directives). For example, for implementations that support SDL, the `@deprecated` directive will be available to annotate deprecated parts of the schema:
+
+```graphql
+type User {
+  fullName: String
+  name: String @deprecated(reason: "Use `fullName`.")
+}
+```
+
+While you won't need to define the `@deprecated` directive in your schema explicitly if you're using a GraphQL implementation that supports SDL, it's underlying definition would look like this:
+
+```graphql
+directive @deprecated(
+  reason: String = "No longer supported"
+) on FIELD_DEFINITION | ENUM_VALUE
+```
+
+Note that, just like fields, directives can accept arguments and those arguments can have default values. The `@deprecated` directive has a nullable `reason` argument that accepts a `String` as an input type and falls back to `"No longer supported"`. And with directives, we must specify where they may be used, such as on a `FIELD_DEFINITION` or `ENUM_VALUE` for the `@deprecated` directive.
+
+In addition to GraphQL's built-in directives, you may define your own _custom directives_. As with custom Scalar types, it's up to your chosen GraphQL implementation to determine how to handle custom directives during query execution.
+
+## Documentation
+
+### Descriptions
+
+GraphQL allows you to add documentation to the types, fields, and arguments in a schema. In fact, the GraphQL specification encourages you to do this in all cases unless the name of the type, field, or argument is self-descriptive. Schema descriptions are defined using Markdown syntax and can be multiline or single line. 
+
+In SDL, they would look like this:
+
+```graphql
+"""
+A character from the Star Wars universe
+"""
+type Character {
+  "The name of the character."
+  name: String!
+}
+
+"""
+The episodes in the Star Wars trilogy
+"""
+enum Episode {
+  "Star Wars Episode IV: A New Hope, released in 1977." 
+  NEWHOPE
+  "Star Wars Episode V: The Empire Strikes Back, released in 1980."
+  EMPIRE
+  "Star Wars Episode VI: Return of the Jedi, released in 1983."
+  JEDI
+}
+
+"""
+The query type, represents all of the entry points into our object graph
+"""
+type Query {
+  """
+  Fetches the hero of a specified Star Wars film.
+  """
+  hero(
+    "The name of the film that the hero appears in."
+    episode: Episode
+  ): Character
+}
+```
+
+In addition to making a GraphQL API schema more expressive, descriptions are helpful to client developers because they are available in [introspection queries](/learn/introspection/) and visible in developer tools such as [GraphiQL](https://github.com/graphql/graphiql).
+
+### Comments
+
+Occasionally, you may need to add comments in a schema that do not describe types, fields, or arguments, and are not meant to be seen by clients. In those cases, you can add a single-line comment to SDL by preceding the text with a `#` character:
+
+```graphql
+# This line is treated like whitespace and ignored by GraphQL
+type Character {
+  name: String!
+}
+```
+
+Comments may also be added to client queries:
+
+```graphql
+# { "graphiql": true }
+{
+  hero {
+    name
+    # Queries can have comments!
+    friends {
+      name
+    }
+  }
+}
+```
+
+## Next steps
+
+To recap what we've learned about schemas and types:
+
+- Depending on what library is selected to build a GraphQL service, we can define a schema in a language-agnostic way using SDL or by compiling the schema from the code that provides data for its fields
+- There are six kinds of named type definitions in GraphQL: Object, Scalar, Enum, Interface, Union, and Input Object types
+- Object types contain fields that specify output types, and those fields may have arguments that specify input types
+- The `Int`, `Float`, `String`, `Boolean`, and `ID` Scalar types are built into GraphQL, and you can also define your own custom scalars
+- Like Scalar types, Enum types represent leaf values in a GraphQL schema but they are limited to a finite set of values
+- The List (`[]`) and Non-Null (`!`) type modifiers allow you to change the default behavior for a field's output type or argument's input type
+- Interface and Union types are abstract types that allow different concrete Object types to be output from a single field
+- Input Object types allow you to pass more complex values into a field argument or directive argument than Scalar and Enum types allow
+- Type system directives can be applied to the types, fields, and arguments in a schema to alter how they are validated and executed during a query
+- GraphQL supports schema documentation using type, field, and argument descriptions, and it also supports comments that are ignored by the parser
+
+Now that you understand the key features of the type system, you're ready to learn more about how to [query data from a GraphQL API](/learn/queries/).
\ No newline at end of file
diff --git a/src/pages/learn/security.mdx b/src/pages/learn/security.mdx
new file mode 100644
index 0000000000..c3945b744d
--- /dev/null
+++ b/src/pages/learn/security.mdx
@@ -0,0 +1,202 @@
+# Security
+
+<p className="learn-subtitle">Protect GraphQL APIs from malicious operations</p>
+
+As with any type of API, you will need to consider what security measures should be used to protect a GraphQL implementation's server resources and underlying data sources during request execution.
+
+Many generalizable API security best practices apply to GraphQL, especially in relation to a given implementation's selected transport protocol. However, there are GraphQL-specific security considerations that will make the API layer more resilient to potential attacks too.
+
+On this page, we'll survey potential attack vectors for GraphQL—many of which are denial of service attacks—along with how a layered security posture can help protect a GraphQL API from malicious operations.
+
+## Transport layer security
+
+The GraphQL specification does not require a specific transport protocol for requests, but [HTTP is a popular choice](/learn/serving-over-http/) for stateless query and mutation operations. For longer-lived subscription operations, WebSockets or server-sent events are often used. Whatever the chosen protocol, security considerations in the transport layer can provide an important first line of defense for a GraphQL API.
+
+The same security measures that would be used for any type of API served with a given transport protocol should typically be used for GraphQL as well. For example, when using HTTP for queries and mutations, you should use HTTPS to encrypt data, set appropriate timeout durations for requests, and, if using HTTP caching, ensure sensitive data is cached privately (or not at all).
+
+## Demand control
+
+### Trusted documents
+
+For GraphQL APIs that only serve first-party clients, you can write operations as needed in development environments and then lock those operations so that only they may be sent by front-end apps in production. Specifically, using _trusted documents_ will allow you to create an allowlist of operations that can be executed against a schema.
+
+As a build step during development clients may submit their GraphQL documents to the server's allowlist, where each document is stored with a unique ID—usually its hash. At runtime, the client can send a document ID instead of the full GraphQL document, and the server will only execute requests for known document IDs.
+
+Trusted documents are simply _persisted documents_ that are deemed to not be malicious, usually because they were authored by your developers and approved through code review. Efforts are underway to [standardize _persisted documents_ as part of the GraphQL-over-HTTP specification](https://github.com/graphql/graphql-over-http/pull/264)—an increasing number of GraphQL clients and servers already support them (sometimes under their legacy misnomer: _persisted queries_).
+
+Keep in mind that trusted documents can't be used for public APIs because the operations sent by third-party clients won't known in advance. However, the other recommendations that follow can help defend a public GraphQL API from malicious operations.
+
+### Paginated fields
+
+A first step toward implementing demand control for a GraphQL API is limiting the amount of data that can be queried from a single field. When a field outputs a List type and the resulting list could potentially return a lot of data, it should be paginated to limit the maximum number of items that may be returned in a single request.
+
+For example, compare the unbounded output of the `friends` field to the limited data returned by the `friendsConnection` field in this operation:
+
+```graphql
+# { "graphiql": true }
+query {
+  hero {
+    name
+    friends {
+      name
+    }
+    friendsConnection(first: 1) {
+      edges {
+        node {
+          name
+        }
+      }
+    }
+  }
+}
+```
+
+Read more about the connection-based model for paginating fields on the [Pagination page](/learn/pagination/).
+
+### Depth limiting
+
+One of GraphQL's strengths is that clients can write expressive operations that reflect the relationships between the data exposed in the API. However, some queries may become cyclical when the fields in the selection set are deeply nested: 
+
+```graphql
+query {
+  hero {
+    name
+    friends {
+      name
+      friends {
+        name
+        friends {
+          name
+          friends {
+            name
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+Even when [the N+1 problem](/learn/performance/#the-n1-problem) has been remediated through batched requests to underlying data sources, overly nested fields may still place excessive load on server resources and impact API performance. 
+
+For this reason, it's a good idea to limit the maximum depth of fields that a single operation can have. Many GraphQL implementations expose configuration options that allow you to specify a maximum depth for a GraphQL document and return an error to the client if a request exceeds this limit before execution begins.
+
+Since nesting list fields can result in exponential increases to the amount of data returned, it's recommended to apply a separate smaller limit to how deeply lists can be nested.
+
+For cases where a client may have a legitimate use case for a deeply nested query and it's impractical to set a low blanket limit on all queries, you may need to rely on techniques such as [rate limiting](/#rate-limiting) or [query complexity analysis](#query-complexity-analysis).
+
+### Breadth and batch limiting
+
+In addition to limiting operation depth, there should also be guardrails in place to limit the number of top-level fields and field aliases included in a single operation.
+
+Consider what would happen during the execution of the following query operation:
+
+```graphql
+query {
+  viewer {
+    friends1: friends(limit: 1) { name }
+    friends2: friends(limit: 2) { name }
+    friends3: friends(limit: 3) { name }
+    # ...
+    friends100: friends(limit: 100) { name }
+  }
+}
+```
+
+Even though the overall depth of this query is shallow, the underlying data source for the API will still have to handle a large number of requests to resolve data for the aliased `hero` field.
+
+Similarly, a client may send a GraphQL document with many batched operations in a request:
+
+```graphql
+query NewHopeHero {
+  hero(episode: NEWHOPE) {
+    name
+  }
+}
+query EmpireHero {
+  hero(episode: EMPIRE) {
+    name
+  }
+}
+### ...
+query JediHero {
+  hero(episode: JEDI) {
+    name
+  }
+}
+```
+
+Depending on the client implementation, query batching can be a useful strategy for limiting the number of round trips to a server to fetch all of the required data to render a user interface. However, there should be an upper limit on the total number of queries allowed in a single batch.
+
+As with depth limiting, a GraphQL implementation may have configuration options to restrict operation breadth, field alias usage, and batching.
+
+### Rate limiting
+
+Depth, breadth, and batch limiting help prevent broad categories of malicious operations such as cyclic queries and batching attacks, but they don't provide a way to declare that a particular field is computationally expensive to resolve. So for more advanced demand control requirements, you may wish to implement rate limiting. 
+
+Rate limiting may take place in different layers of an application, for example, in the network layer or the business logic layer. Because GraphQL allows clients to specify exactly what data they need in their queries, a server may not be able to know in advance if a request includes fields that will place a higher load on its resources during execution. As a result, applying useful rate limits for a GraphQL API typically requires a different approach than simply keeping track of the total number of incoming requests over a time period in the network layer; therefore applying rate limits within the business logic layer is generally recommended.
+
+### Query complexity analysis
+
+By applying weights to the types and fields in a schema, you can estimate the cost of incoming requests using the technique known as _query complexity analysis_. If the combination of fields included in a request exceeds a maximum allowable cost per request, you may choose to reject the request outright. The estimated cost can also be factored into rate limiting: if the request proceeds, the total cost of the request can be deducted from the overall query budget allocated to a client for a specific time period.
+
+While the GraphQL specification doesn't provide any guidelines on implementing query complexity analysis or rate limits for an API, there is [a community-maintained draft specification](https://ibm.github.io/graphql-specs/cost-spec.html) for implementing custom type system directives that support these calculations.
+
+## Schema considerations
+
+### Validating and sanitizing argument values
+
+GraphQL is strongly typed, and the [validation stage](/learn/validation/) of a request will check a parsed document against the type system to determine its validity. However, for certain cases you may find that the built-in Scalar types aren't enough to make sure that the argument value a client provides is appropriate to execute a field resolver safely.
+
+Consider the following `ReviewInput` type that is used with the `createReview` mutation: 
+
+```graphql
+input ReviewInput {
+  stars: Int!
+  commentary: String
+}
+
+type Mutation {
+  createReview(episode: Episode, review: ReviewInput!): Review
+}
+```
+
+Depending on what kind of client application will submit and display the review data, it may be necessary to sanitize the string provided for the `commentary` field in case a user submits unsafe HTML in it.
+
+The sanitization step should take place in the business logic layer that is called during execution of the `createReview` resolver function. To surface this to frontend developers, it could also be expressed as a part of the schema using a custom [Scalar type](/learn/schema/#scalar-types).
+
+### Introspection
+
+[Introspection](/learn/introspection/) is a powerful feature of GraphQL that allows you to query a GraphQL API for information about its schema. However, GraphQL APIs that only serve first-party clients may forbid introspection queries in non-development environments.
+
+Note that disabling introspection can be used as a form of "security through obscurity," but will not be sufficient to entirely obscure a GraphQL API by itself. It may be used as a part of a broader security strategy to limit the discoverability of API information from potential attackers. For more comprehensive protection of sensitive schema details and user data, trusted documents and authorization should be used.
+
+### Error messages
+
+On the [Response page](/learn/response/), we saw that a GraphQL implementation may provide developers with useful information about validation errors in a request, along with suggestions for how these errors may be addressed. For example:
+
+```graphql
+# { "graphiql": true }
+query {
+  starship(id: 3000) {
+    width
+  }
+}
+```
+
+These hints can be helpful when debugging client-side errors, but they may provide more information about a schema in a production environment than we would like to reveal. Hiding detailed error information in GraphQL responses outside of development environments is important because, even with introspection disabled, an attacker could ultimately infer the shape of an entire schema by running numerous operations with incorrect field names.
+
+In addition to request errors, details about errors that are raised during field execution should be masked as they may reveal sensitive information about the server or underlying data sources.
+
+## Authentication and authorization
+
+Auth-related considerations for GraphQL APIs are discussed in-depth on the [Authorization page](/learn/authorization/).
+
+## Recap
+
+To recap these recommendations for securing a GraphQL API:
+
+- General security considerations for a chosen transport protocol will usually apply to a GraphQL API as well
+- Depending on your requirements, demand control can be implemented in many ways in GraphQL, including trusted documents, pagination of list fields, depth limiting, breadth/batch limiting, and rate limiting
+- A GraphQL schema can help support validation and sanitization of client-provided values
+- Disabling introspection and obscuring error information can make an API's schema less discoverable, but they will typically not be sufficient when used on their own (a document allowlist is likely to be a more effective solution)
\ No newline at end of file
diff --git a/src/pages/learn/serving-over-http.mdx b/src/pages/learn/serving-over-http.mdx
index 03b00ef5f9..22021696cf 100644
--- a/src/pages/learn/serving-over-http.mdx
+++ b/src/pages/learn/serving-over-http.mdx
@@ -1,22 +1,65 @@
+import { Callout } from "nextra/components"
+
 # Serving over HTTP
 
-HTTP is the most common choice for client-server protocol when using GraphQL because of its ubiquity. Here are some guidelines for setting up a GraphQL server to operate over HTTP.
+<p className="learn-subtitle">Respond to GraphQL requests using an HTTP server</p>
+
+The GraphQL specification doesn't require paricular client-server protocols when sending API requests and responses, but HTTP is the most common choice because of its ubiquity. On this page, we'll review some key guidelines to follow when setting up a GraphQL server to operate over HTTP.
+
+Note that the guidelines that follow only apply to stateless query and mutation operations. Visit the [Subscriptions page](/learn/subscriptions) for more information on transport protocols that commonly support these requests.
+
+<Callout type="info">
+The recommendations on this page align with the detailed [GraphQL-over-HTTP specification](https://graphql.github.io/graphql-over-http/draft/) currently in development. Though not yet finalized, this draft specification acts as a single source of truth for GraphQL client and library maintainers, detailing how to expose and consume a GraphQL API using an HTTP transport. Unlike the language specification, adherence is not mandatory, but most implementations are moving towards these standards to maximize interoperability.
+</Callout>
+
+## API endpoint
+
+HTTP is commonly associated with REST, which uses "resources" as its core concept. In contrast, GraphQL's conceptual model is an [entity graph](/learn/thinking-in-graphs/). As a result, entities in GraphQL are not identified by URLs. Instead, a GraphQL server operates on a single URL/endpoint, usually `/graphql`, and all GraphQL requests for a given service should be directed to this endpoint.
+
+## Where auth happens
+
+Most modern web frameworks use a pipeline model where requests are passed through a stack of _middleware_, also known as _filters_ or _plugins_. As the request flows through the pipeline, it can be inspected, transformed, modified, or terminated with a response. GraphQL should be placed after all authentication middleware so that you have access to the same session and user information you would in your other HTTP endpoint handlers.
+
+After authentication, the server should not make any [authorization](/learn/authorization/) decisions about the request until GraphQL execution begins. Specifically, field-level authorization should be enforced by the business logic called from resolvers during [GraphQL's ExecuteRequest()](https://spec.graphql.org/draft/#ExecuteRequest()), allowing for a partial response to be generated if authorization-related errors are raised.
+
+## Request format
 
-## Web Request Pipeline
+### Headers
 
-Most modern web frameworks use a pipeline model where requests are passed through a stack of middleware (AKA filters/plugins). As the request flows through the pipeline, it can be inspected, transformed, modified, or terminated with a response. GraphQL should be placed after all authentication middleware, so that you have access to the same session and user information you would in your HTTP endpoint handlers.
+GraphQL clients and servers should support JSON for serialization and may support other formats. Clients should also indicate what media types they support in responses using the `Accept` HTTP header. Specifically, the client should include the `application/graphql-response+json` in the `Accept` header.
 
-## URIs, Routes
+If no encoding information is included with this header, then it will be assumed to be `utf-8`. However, the server may respond with an error if a client doesn't provide the `Accept` header with a request.
+
+<Callout type="info">
+The `application/graphql-response+json` is described in the draft GraphQL over HTTP specification. To ensure compatibility, if a client sends a request to a legacy GraphQL server before 1st January 2025, the `Accept` header should also include the `application/json` media type as follows: `application/graphql-response+json;charset=utf-8, application/json;charset=utf-8`
+</Callout>
+
+### Methods
+
+Your GraphQL HTTP server must handle the HTTP `POST` method for query and mutation operations, and may also accept the `GET` method for query operations.
+
+#### `POST` request and body
+
+A standard GraphQL POST request should set `application/json` for its `Content-type` header, and include a JSON-encoded body of the following form:
+
+```json
+{
+  "query": "...",
+  "operationName": "...",
+  "variables": { "myVariable": "someValue", ... },
+  "extensions": { "myExtension": "someValue", ... }
+}
+```
 
-HTTP is commonly associated with REST, which uses "resources" as its core concept. In contrast, GraphQL's conceptual model is an entity graph. As a result, entities in GraphQL are not identified by URLs. Instead, a GraphQL server operates on a single URL/endpoint, usually `/graphql`, and all GraphQL requests for a given service should be directed at this endpoint.
+The `query` parameter is required and will contain the source text of a GraphQL document. Note that the term `query` here is a misnomer: the document may contain any valid GraphQL operations (and associated fragments).
 
-## HTTP Methods, Headers, and Body
+The `operationName`, `variables`, and `extensions` parameters are optional fields. `operationName` is only required if multiple operations are present in the `query` document.
 
-Your GraphQL HTTP server should handle the HTTP GET and POST methods.
+Note that if the `Content-type` header is missing in the client's request, then the server should respond with a `4xx` status code. As with the `Accept` header, `utf-8` encoding is assumed for a request body with an `application/json` media type when this information is not explicitly provided.
 
-### `GET` request
+#### `GET` request and parameters
 
-When receiving an HTTP GET request, the GraphQL query should be specified in the "query" query string. For example, if we wanted to execute the following GraphQL query:
+When receiving an HTTP GET request, the GraphQL document should be provided in the `query` parameter of the query string. For example, if we wanted to execute the following GraphQL query:
 
 ```graphql
 {
@@ -34,37 +77,63 @@ http://myapi/graphql?query={me{name}}
 
 Query variables can be sent as a JSON-encoded string in an additional query parameter called `variables`. If the query contains several named operations, an `operationName` query parameter can be used to control which one should be executed.
 
-### `POST` request
+#### Choosing an HTTP method
 
-A standard GraphQL POST request should use the `application/json` content type, and include a JSON-encoded body of the following form:
+When choosing an HTTP method for a GraphQL request, there are a few points to consider. First, support for HTTP methods other than `POST` will be at the discretion of the GraphQL server, so a client will be limited to the supported verbs.
 
-```json
-{
-  "query": "...",
-  "operationName": "...",
-  "variables": { "myVariable": "someValue", ... }
-}
-```
+Additionally, the `GET` HTTP method may only be used for `query` operations, so if a client requests execution of a `mutation` operation then it must use the `POST` method instead.
+
+When servers do support the `GET` method for query operations, a client may be encouraged to leverage this option to facilitate HTTP caching or edge caching in a content delivery network (CDN). However, because GraphQL documents strings may be quite long for complex operations, the query parameters may exceed the limits that browsers and CDNs impose on URL lengths.
+
+In these cases, a common approach is for the server to store identified GraphQL documents using a technique such as [_persisted documents_](https://github.com/graphql/graphql-over-http/pull/264), _automatic persisted queries_, or _trusted documents_. This allows the client to send a short document identifier instead of the full query text.
 
-`operationName` and `variables` are optional fields. `operationName` is only required if multiple operations are present in the query.
+## Response format
 
-## Response
+### Headers
 
-Regardless of the method by which the query and variables were sent, the response should be returned in the body of the request in JSON format. As mentioned in the spec, a query might result in some data and some errors, and those should be returned in a JSON object of the form:
+The response type should be `application/graphql-response+json` but can be `application/json` to support legacy clients. The server will indicate the media type in the `Content-type` header of the response. It should also indicate the encoding, otherwise `utf-8` will be assumed.
+
+### Body
+
+Regardless of the HTTP method used to send the query and variables, the response should be returned in the body of the request in JSON format. As mentioned in the GraphQL specification, a query might result in some data and some errors, and those should be returned in a JSON object of the form:
 
 ```json
 {
   "data": { ... },
-  "errors": [ ... ]
+  "errors": [ ... ],
+  "extensions": { ... }
 }
 ```
 
-If there were no errors returned, the `"errors"` field should not be present on the response. If no data is returned, [according to the GraphQL spec](https://spec.graphql.org/October2021/#sec-Data), the `"data"` field should only be included if no errors occurred during execution.
+If no errors were returned, the `errors` field must not be present in the response. If errors occurred before execution could start, the `errors` field must include these errors and the `data` field must not be present in the response. The `extensions` field is optional and information provided here will be at the discretion of the GraphQL implementation.
+
+You can read more about GraphQL spec-compliant response formats on the [Response page](/learn/response/).
+
+### Status Codes
+
+If a response contains a `data` key and its value is not `null`, then the server should respond with a `2xx` status code for either the `application/graphql-response+json` or `application/json` media types. This is the case even if the response includes errors, since HTTP does not yet have a status code representing "partial success."
+
+For validation errors that prevent the execution of a GraphQL operation, the server will typically send a `400` status code, although some legacy servers may return a `2xx` status code when the `application/json` media type is used.
+
+For legacy servers that respond with the `application/json` media type, the use of `4xx` and `5xx` status codes for valid GraphQL requests that fail to execute is discouraged but may be used depending on the implementation. Because of potential ambiguities regarding the source of the server-side error, a `2xx` code should be used with this media type instead.
+
+However, for responses with the `application/graphql-response+json` media type, the server will reply with a `4xx` or `5xx` status code if a valid GraphQL request fails to execute.
+
+## Server implementations
+
+If you use Node.js, we recommend looking at the [list of JS server implementations](/community/tools-and-libraries/?tags=javascript_server).
 
-## Node
+You can view a [list of servers written in many other languages here](/community/tools-and-libraries/?tags=server).
 
-If you are using Node.js, we recommend looking at the [list of server implementations](/code/#javascript-server).
+## Recap
 
-## Draft Transport Specification
+To recap these recommendations for serving GraphQL over HTTP:
 
-A detailed [HTTP transport specification](https://github.com/graphql/graphql-over-http) is in development. Though it is not yet finalized, these draft specifications act as a single source of truth for GraphQL client & library maintainers, detailing how to expose and consume a GraphQL API using an HTTP transport. Unlike the language specification, adherence is not mandatory, but most implementations are moving towards these standards to maximize interoperability.
+- The server should handle user authentication before a GraphQL request is validated; authorization should happen within your business logic during GraphQL request execution
+- GraphQL APIs are exposed at a single endpoint, typically ending with `/graphql`
+- GraphQL clients and servers should support JSON, but may support other formats
+- Client should indicate a media type on the `Accept` header of `application/graphql-response+json`
+- GraphQL requests are sent using the `POST` HTTP method, but query operations may also be sent using the `GET` method
+- Clients should also provide a `Content-type` header with a value of `application/json` for `POST` requests
+- The full or partial result of an executed GraphQL operation will be available on the `data` key in the JSON-encoded body of the response, while information about any errors raised during validation or execution will be available on the `errors` key
+- Response status codes for valid GraphQL operations that fail may vary depending on the indicated media type of the response, but any GraphQL response with a non-null `data` key will provide a `2xx` response
diff --git a/src/pages/learn/validation.mdx b/src/pages/learn/validation.mdx
index da6593424b..7d830c55a4 100644
--- a/src/pages/learn/validation.mdx
+++ b/src/pages/learn/validation.mdx
@@ -1,97 +1,47 @@
 # Validation
 
-By using the type system, it can be predetermined whether a GraphQL query
-is valid or not. This allows servers and clients to effectively inform
-developers when an invalid query has been created, without having to rely
-on runtime checks.
+<p className="learn-subtitle">Learn how GraphQL validates operations using a schema</p>
 
-For our Star Wars example, the file
-[starWarsValidation-test.ts](https://github.com/graphql/graphql-js/blob/main/src/__tests__/starWarsValidation-test.ts)
-contains a number of queries demonstrating various invalidities, and is a test
-file that can be run to exercise the reference implementation's validator.
+On this page, we'll explore an important phase in the lifecycle of a GraphQL request called [validation](https://spec.graphql.org/draft/#sec-Validation). A request must be syntactically correct to run, but it should also be valid when checked against the API's schema. 
 
-To start, let's take a complex valid query. This is a nested query, similar to
-an example from the previous section, but with the duplicated fields factored
-out into a fragment:
+In practice, when a GraphQL operation reaches the server, the document is first parsed and then validated using the type system. This allows servers and clients to effectively inform developers when an invalid query has been created, without relying on runtime checks. Once the operation is validated, it can be [executed](/learn/execution/) on the server and a response will be delivered to the client.
 
-```graphql
-# { "graphiql": true }
-{
-  hero {
-    ...NameAndAppearances
-    friends {
-      ...NameAndAppearances
-      friends {
-        ...NameAndAppearances
-      }
-    }
-  }
-}
+## Validation examples
 
-fragment NameAndAppearances on Character {
-  name
-  appearsIn
-}
-```
+The GraphQL specification describes the detailed conditions that must be satisfied for a request to be considered valid. In the sections that follow, we'll look at a few examples of common validation issues that may occur in GraphQL operations.
 
-And this query is valid. Let's take a look at some invalid queries...
+### Requesting non-existent fields
 
-A fragment cannot refer to itself or create a cycle, as this could result in
-an unbounded result! Here's the same query above but without the explicit three
-levels of nesting:
-
-```graphql
-# { "graphiql": true }
-{
-  hero {
-    ...NameAndAppearancesAndFriends
-  }
-}
-
-fragment NameAndAppearancesAndFriends on Character {
-  name
-  appearsIn
-  friends {
-    ...NameAndAppearancesAndFriends
-  }
-}
-```
-
-When we query for fields, we have to query for a field that exists on the
-given type. So as `hero` returns a `Character`, we have to query for a field
-on `Character`. That type does not have a `favoriteSpaceship` field, so this
-query is invalid:
+When we query for a field, the field must be defined on the relevant type. As `hero` returns a `Character` type, its selection set may only request the `Character` type's fields; `Character` does not have a `favoriteSpaceship` field, so this query is invalid:
 
 ```graphql
 # { "graphiql": true }
 # INVALID: favoriteSpaceship does not exist on Character
-{
+query {
   hero {
     favoriteSpaceship
   }
 }
 ```
 
-Whenever we query for a field and it returns something other than a scalar
-or an enum, we need to specify what data we want to get back from the field.
-Hero returns a `Character`, and we've been requesting fields like `name` and
-`appearsIn` on it; if we omit that, the query will not be valid:
+### Selection sets and leaf fields
+
+Whenever we query for a field and it returns something other than a Scalar or Enum type, we need to specify what data we want to get back from the field (a "selection set"). The `hero` query field returns a `Character`, and we've already seen examples that request fields like `name` and `appearsIn` on it. If we omit those leaf field selections, then the query will not be valid:
 
 ```graphql
 # { "graphiql": true }
 # INVALID: hero is not a scalar, so fields are needed
-{
+query {
   hero
 }
 ```
 
-Similarly, if a field is a scalar, it doesn't make sense to query for
-additional fields on it, and doing so will make the query invalid:
+Similarly, querying fields of a scalar or enum doesn’t make sense, therefore adding a selection set to a leaf field will make the query invalid:
 
 ```graphql
 # { "graphiql": true }
 # INVALID: name is a scalar, so fields are not permitted
-{
+query {
   hero {
     name {
       firstCharacterOfName
@@ -100,15 +50,14 @@ additional fields on it, and doing so will make the query invalid:
 }
 ```
 
-Earlier, it was noted that a query can only query for fields on the type
-in question; when we query for `hero` which returns a `Character`, we
-can only query for fields that exist on `Character`. What happens if we
-want to query for R2-D2s primary function, though?
+### Missing fragments for fields that output abstract types
+
+Earlier, it was noted that a query can only ask for fields on the type in question. So when we query for `hero` which returns a `Character`, we can only request fields that exist on the `Character` Interface type. What happens if we want to query for R2-D2's primary function, though?
 
 ```graphql
 # { "graphiql": true }
 # INVALID: primaryFunction does not exist on Character
-{
+query {
   hero {
     name
     primaryFunction
@@ -116,16 +65,11 @@ want to query for R2-D2s primary function, though?
 }
 ```
 
-That query is invalid, because `primaryFunction` is not a field on `Character`.
-We want some way of indicating that we wish to fetch `primaryFunction` if the
-`Character` is a `Droid`, and to ignore that field otherwise. We can use
-the fragments we introduced earlier to do this. By setting up a fragment defined
-on `Droid` and including it, we ensure that we only query for `primaryFunction`
-where it is defined.
+That query is invalid, because `primaryFunction` is not one of the shared fields defined by the `Character` Interface type. We want some way of indicating that we wish to fetch `primaryFunction` if the `Character` is a `Droid`, and to ignore that field otherwise. We can use the [fragments](/learn/queries/#fragments) to do this. By setting up a fragment defined on `Droid` and including it in the selection set, we ensure that we only query for `primaryFunction` where it is defined:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   hero {
     name
     ...DroidFields
@@ -137,15 +81,11 @@ fragment DroidFields on Droid {
 }
 ```
 
-This query is valid, but it's a bit verbose; named fragments were valuable
-above when we used them multiple times, but we're only using this one once.
-Instead of using a named fragment, we can use an inline fragment; this
-still allows us to indicate the type we are querying on, but without naming
-a separate fragment:
+This query is valid, but it's a bit verbose; named fragments were valuable above when we used them multiple times, but we're only using this one once. Instead of using a named fragment, we can use an [inline fragment](/learn/queries/#inline-fragments); this still allows us to indicate the type we are querying on, but without naming a separate fragment:
 
 ```graphql
 # { "graphiql": true }
-{
+query {
   hero {
     name
     ... on Droid {
@@ -155,10 +95,63 @@ a separate fragment:
 }
 ```
 
-This has just scratched the surface of the validation system; there
-are a number of validation rules in place to ensure that a GraphQL query
-is semantically meaningful. The specification goes into more detail about this
-topic in the "Validation" section, and the
-[validation](https://github.com/graphql/graphql-js/blob/main/src/validation)
-directory in GraphQL.js contains code implementing a
-specification-compliant GraphQL validator.
+### Cyclic fragment spreads
+
+To start, let's take a complex valid query. This is a nested query, but with the duplicated fields factored out into a fragment:
+
+```graphql
+# { "graphiql": true }
+query {
+  hero {
+    ...NameAndAppearances
+    friends {
+      ...NameAndAppearances
+      friends {
+        ...NameAndAppearances
+      }
+    }
+  }
+}
+
+fragment NameAndAppearances on Character {
+  name
+  appearsIn
+}
+```
+
+The following is an alternative to the above query, attempting to use recursion instead of the explicit three levels of nesting. This new query is invalid because a fragment cannot refer to itself (directly or indirectly) since the resulting cycle could create an unbounded result!
+
+```graphql
+# { "graphiql": true }
+query {
+  hero {
+    ...NameAndAppearancesAndFriends
+  }
+}
+
+fragment NameAndAppearancesAndFriends on Character {
+  name
+  appearsIn
+  friends {
+    ...NameAndAppearancesAndFriends
+  }
+}
+```
+
+This has just scratched the surface of the validation system; there are a number of validation rules in place to ensure that a GraphQL operation is semantically meaningful. The specification goes into more detail about this topic in the [validation section](https://spec.graphql.org/draft/#sec-Validation), and the [validation directory in the reference implementation](https://github.com/graphql/graphql-js/blob/main/src/validation) contains code implementing a specification-compliant GraphQL validator.
+
+## Validation errors
+
+As we have seen in the examples above, when a GraphQL server encounters a validation error in a request, it will return information about what happened in the `errors` key of the response. Specifically, when GraphQL detects a validation issue in a document, it raises a _request error_ before execution begins, meaning that no partial data will be included in the response.
+
+And because the GraphQL specification requires all implementations to validate incoming requests against the schema, developers won't need to write specific runtime logic to handle these validation issues manually.
+
+## Next steps
+
+To recap what we've learned about validation:
+
+- To be executed, requests must include a syntactically correct document that is considered valid when checked against the schema
+- The specification requires implementations check incoming requests contain valid field selections, correct fragment usage, and more
+- When a validation issue occurs, the server will raise a request error and return to the client information about what happened; field execution will not start
+
+Head over to the [Execution](/learn/execution/) page to learn how GraphQL provides data for each field in a request after the validation step successfully completes.
\ No newline at end of file