Merge branch 'develop' into docs/spotify

.eslintrc.json

@@ -0,0 +1,17 @@
+{
+  "parser": "@babel/eslint-parser",
+  "parserOptions": {
+    "ecmaVersion": 2021,
+    "sourceType": "module",
+    "requireConfigFile": false
+  },
+  "extends": ["plugin:@docusaurus/recommended", "plugin:@typescript-eslint/recommended"],
+  "plugins": ["@docusaurus", "@typescript-eslint"],
+  "rules": {
+    "@docusaurus/string-literal-i18n-messages": "error",
+    "@docusaurus/no-html-links": "error",
+    "@typescript-eslint/no-explicit-any": ["error", {"ignoreRestArgs": true}]
+    // Add other TypeScript rules as needed
+  },
+  "ignorePatterns": ["node_modules/", "build/"]
+}

.github/ISSUE_TEMPLATE/write-a-guide.md

@@ -1,29 +1,33 @@
 ---
 name: Write a Guide
 about: Template to write guides
-title: 'doc: '
-labels: ''
-assignees: ''
-
+title: "doc: "
+labels: ""
+assignees: ""
 ---
 
 <!-- Describe the requirements here -->
 
 ## Content Creation Requirements
+
 To maintain the quality of our content, please adhere to the following guidelines:
 
 ### 1. Accuracy in Language
+
 - **Grammar and Spelling:** Ensure your content is free from grammatical and spelling errors.
 
 ### 2. Tone and Style
+
 - **Neutral Tone:** Maintain a neutral, non-emotional tone throughout the content.
 - **Engaging Style:** Write in a free-flowing and engaging manner, keeping the reader's interest.
 
 ### 3. Content Integrity
+
 - **Fact-Checking:** Verify all information. If unsure, use Discord to clarify.
 - **Relevance:** Ensure all content is cohesive, to the point, and directly related to the title.
 
 ### 4. Originality
+
 - **Avoid Low-Effort Content:** Content should be original and not solely generated by AI tools like ChatGPT.
 
 **PS: Adherence to these guidelines is crucial. Content not meeting these standards may require revision or may not be accepted.**

.github/workflows/grammar-check.yml

@@ -0,0 +1,26 @@
+name: Check grammar
+
+on:
+  pull_request:
+    paths:
+      - "docs/**"
+      - "**.md"
+
+jobs:
+  check-grammar:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: "19"
+
+      - name: Install write-good
+        run: npm install write-good
+
+      - name: Check grammar
+        run: npx write-good docs/**/*.md

docs/getting_started/installation.mdx

@@ -9,8 +9,7 @@ import Version from "../../src/components/Version"
 import InstallCommand from "../../src/components/install"
 
 <>
-  You can install the latest version -{" "}
-  **<Version />**, by using<b> NPM</b>.
+  You can install the latest version - <b><Version /></b>, by using<b> NPM</b>.
 </>
 ## NPM
 

docs/intro/introduction.md

@@ -6,16 +6,16 @@ slug: /
 
 ## Traditional API Gateway
 
-Traditional API Gateways form the backbone of modern web based application architectures, offering a comprehensive suite of features essential for efficient API management. These gateways handle tasks such as routing, authentication, circuit breaking, caching, logging, monitoring, protocol translation and the list doesn't end!
+Traditional API Gateways ("TAGs") form the backbone of modern web based application architectures, offering a comprehensive suite of features essential for efficient API management. These gateways handle tasks such as routing, authentication, circuit breaking, caching, logging, monitoring, protocol translation and the list doesn't end!
 
-However, API Gateways don't provide developers access to the right abstraction when it comes to configuring these capabilities. Typically a TAG would provide you with primitives that are based on the underlying protocol ie. on which the API is served. For eg: You can perform authentication, routing, rate-limiting etc. on the bases of the request headers, url or method. All of which are components of the HTTP protocol. This happens because they treat the contents of request and response bodies as mere byte sequences, without delving into their substance.
+However, API Gateways don't provide developers access to the right abstraction when it comes to configuring these capabilities. Typically a TAG would provide you with primitives that are based on the underlying protocol (i.e. the protocol on which the API is served). For example: you can perform authentication, routing, rate-limiting etc. on the basis of the request headers, URL or method. All of which are components of the HTTP protocol. This happens because they treat the contents of request and response bodies as mere byte sequences, without delving into their substance.
 
 Over the years, we have gotten used to consuming and managing APIs this way. Writing our own custom abstractions and sticking it around an existing over the shelf API Gateway. Our personal experience has been that nearly all companies after a certain scale require an abstraction that's specific to their business entities and feel restricted by what the API Gateway can provide.
 
 ## Tailcall API Gateway
 
 Based on our learnings of writing APIs at massive scale, we believe that the gateway should work around an enterprise's business entities and not the other way round. That's exactly what Tailcall helps you achieve.
-Tailcall provides first-class primitives designed to interact with your business entities directly without burdening the developer with the underlying protocol. This approach grants tremendous power and flexibility, transcending protocol constraints and focusing on the nature of the API's data. Let's take a the `User` entity as an example:
+Tailcall provides first-class primitives designed to interact with your business entities directly without burdening the developer with the underlying protocol. This approach grants tremendous power and flexibility, transcending protocol constraints and focusing on the nature of the API's data. Let's take the `User` entity as an example:
 
 ```graphql
 type User {
@@ -31,7 +31,7 @@ type Account {
 }
 ```
 
-`User` is a business entity that can be resolved from multiple APIs. A `/users` API could resolve the `id`, `name` & `email` and a `/accounts/:userId` could resolve the user's account `balance` and `lastUpdated`. With tailcall's API Gateway you will be able to specify just the account details as private and requiring authentication.
+`User` is a business entity that can be resolved from multiple APIs. A `/users` API could resolve the `id`, `name` & `email` and a `/accounts/:userId` could resolve the user's account `balance` and `lastUpdated`. With tailcall's API Gateway you will be able to specify that requests accessing the account details will require authentication, whereas other requests may not.
 
 ```graphql
 type User {

docusaurus.config.ts

@@ -11,6 +11,14 @@ export default {
   trailingSlash: true,
   tagline: "<tagline>",
   headTags: [
+    {
+      tagName: "script",
+      attributes: {
+        async: "true",
+        src: "https://tag.clearbitscripts.com/v1/pk_498a76355e253f5c7f4e7c7bed78748e/tags.js",
+        referrerPolicy: "strict-origin-when-cross-origin",
+      },
+    },
     {
       tagName: "link",
       attributes: {