docs(510): split directive configuration file

blog/graphql-and-ms-match-2024-08-18.md

@@ -125,7 +125,7 @@ Designing scalable APIs that leverage both **GraphQL** and **microservices** req
 3. **Caching:** Utilize effective caching strategies at both the GraphQL and microservice levels to enhance performance. Caching reduces the need for repeated data retrieval, lowering latency and improving the user experience. Consider using in-memory caches for frequently accessed data and implement cache invalidation strategies to ensure data consistency.
 4. **Monitoring and Logging:** Comprehensive monitoring and logging are vital for tracking API performance, identifying potential bottlenecks, and quickly resolving issues. Implementing detailed logging with tools like OpenTelemetry provides valuable insights into the behavior of your API, helping you maintain high availability and optimize performance over time.
 
-5. **Security:** With **Tailcall's** [built-in auth](https://tailcall.run/docs/field-level-access-control-graphql-authentication/) and [@protected](https://tailcall.run/docs/tailcall-dsl-graphql-custom-directives/#protected-directive) directive, you can add auth functionality and make fields protected with just a few lines of code - which is intelligent enough to protect any query that indirectly resolves to that field:
+5. **Security:** With **Tailcall's** [built-in auth](https://tailcall.run/docs/field-level-access-control-graphql-authentication/) and [@protected](https://tailcall.run/docs/protected-directive) directive, you can add auth functionality and make fields protected with just a few lines of code - which is intelligent enough to protect any query that indirectly resolves to that field:
 
 ```graphql
 type Reaction @protected {

blog/tailcall-n+1-working-2024-08-04.md

@@ -116,7 +116,7 @@ Now, here's where it gets fascinating. We use a Depth-First Search (DFS) algorit
 
 1. Initialize two variables to track the currently traversed `path` and `visited` fields so that we can avoid cycles.
 2. Start at the root query and begin traversing the graph data structure.
-3. For each field in the current node, check if it has a resolver and is not batched. We know if the node contains a resolver if that node has a [`@http`](/docs/tailcall-dsl-graphql-custom-directives#http-directive) or a [`@grpc`](/docs/tailcall-dsl-graphql-custom-directives#grpc-directive). Tailcall supports powerful batching primitives and if a field uses a Batch API, then that resolver is whitelisted and dropped from the list of potential N+1 candidates.
+3. For each field in the current node, check if it has a resolver and is not batched. We know if the node contains a resolver if that node has a [`@http`](/docs/directives/http-directive) or a [`@grpc`](/docs/directives/grpc-directive). Tailcall supports powerful batching primitives and if a field uses a Batch API, then that resolver is whitelisted and dropped from the list of potential N+1 candidates.
 4. If the field has a resolver and is not batched, and the current path contains a list, then the current path is added to the result.
 5. Otherwise, we recursively traverse the graph data structure, updating the current path and visited fields as necessary.
 6. If a cycle is detected, return the cached result instead of re-traversing the path.

docs/N+1.md

@@ -175,7 +175,7 @@ If you run the query, at first you will observe a lot of duplicate requests are
 
 ![Duplicate Upstream Calls](../static/images/docs/n+1-duplicate.png)
 
-This happens because of the 100 posts, a lot them are authored by the same user and by default Tailcall will make a request for every user when requested. You can fix this by setting [dedupe](/docs/directives.md#dedupe) to `true` in [server](/docs/directives.md#server-directive).
+This happens because of the 100 posts, a lot them are authored by the same user and by default Tailcall will make a request for every user when requested. You can fix this by setting [dedupe](/docs/directives/server.md#dedupe) to `true` in [server](/docs/directives/server.md).
 
 ```graphql {3}
 schema
@@ -260,7 +260,7 @@ Incredible, isn't it? Tailcall has discovered that querying for posts followed b
 
 ![Batched API](../static/images/docs/n+1-batch.png)
 
-An effective technique to mitigate the N+1 problem is deduplicating similar requests, significantly reducing the number of server calls. We achieved it previously using the [dedupe](/docs/directives.md#dedupe) setting. With Tailcall we can go one step further by giving hints about "batch APIs".
+An effective technique to mitigate the N+1 problem is deduplicating similar requests, significantly reducing the number of server calls. We achieved it previously using the [dedupe](/docs/directives/server.md#dedupe) setting. With Tailcall we can go one step further by giving hints about "batch APIs".
 
 **Batch APIs:** Are special APIs that allow us to query multiple things at once. In our case we can pass multiple user Ids as query params, to the `/users` API to resolve many users at once:
 

docs/apollo-studio.md

@@ -34,7 +34,7 @@ This guide illustrates how to configure `tailcall` to send usage metrics to [Apo
 
       ![local-schema.png](../static/images/apollo-studio/local-schema.png)
 
-You have now created a Monolith graph in Apollo Studio. The next step is to configure `tailcall` to use the `APOLLO_API_KEY` and `APOLLO_GRAPH_REF`. Follow detailed instructions [here](/docs/directives.md#telemetry-directive).
+You have now created a Monolith graph in Apollo Studio. The next step is to configure `tailcall` to use the `APOLLO_API_KEY` and `APOLLO_GRAPH_REF`. Follow detailed instructions [here](/docs/directives/telemetry.md).
 
 ## Checking the metrics in Apollo Studio
 

docs/auth.md

@@ -46,8 +46,8 @@ to know more about how to use it, read the following articles:
 
 Enabling support for authentication in Tailcall could be done in two steps:
 
-1. With the help of [`@link` directive](/docs/directives.md#link-directive) connect multiple authentication files as you need for different provides. To connect it use either [`Htpasswd`](/docs/directives.md#htpasswd) or [`Jwks`](/docs/directives.md#jwks) link type
-2. Mark that some type of field requires authentication to be fetched with the help of [`@protected` directive](/docs/directives.md#protected-directive)
+1. With the help of [`@link` directive](/docs/directives/link.md) connect multiple authentication files as you need for different provides. To connect it use either [`Htpasswd`](/docs/directives/link.md#htpasswd) or [`Jwks`](/docs/directives/link.md#jwks) link type
+2. Mark that some type of field requires authentication to be fetched with the help of [`@protected` directive](/docs/directives/protected.md)
 
 Your config could look like this now:
 
@@ -229,7 +229,7 @@ In case you linked multiple authentication files all of them will be used to exe
 
 ### Authentication headers
 
-To validate authentication for user request the specific headers are used (like `Authorization` header). In case auth is enabled for tailcall those headers will be also added to the [`allowedHeaders` list](/docs/directives.md#allowedheaders) and therefore they will be forwarded to the upstream requests implicitly.
+To validate authentication for user request the specific headers are used (like `Authorization` header). In case auth is enabled for tailcall those headers will be also added to the [`allowedHeaders` list](/docs/directives/upstream.md#allowedheaders) and therefore they will be forwarded to the upstream requests implicitly.
 
 ## Basic Authentication
 
@@ -249,15 +249,15 @@ Since this file stores secure information make sure to hash the password you use
 
 ### Basic Auth GraphQL Configuration
 
-To use Basic Auth you should first include htpasswd file generated from [Prerequisites](#prerequisites) with the help of [`@link` directive](/docs/directives.md#htpasswd).
+To use Basic Auth you should first include htpasswd file generated from [Prerequisites](#prerequisites) with the help of [`@link` directive](/docs/directives/link.md#htpasswd).
 
 We can use that file as an example for it that has data for `testuser:mypassword` credentials in encrypted format:
 
 ```plaintext title="htpasswd"
 testuser:$2y$10$wJ/mZDURcAOBIrswCAKFsO0Nk7BpHmWl/XuhF7lNm3gBAFH3ofsuu
 ```
 
-After adding `@link` you can use the [`@protected` directive](/docs/directives.md#protected-directive) to mark the fields that requiring success authentication to be requested.
+After adding `@link` you can use the [`@protected` directive](/docs/directives/protected.md) to mark the fields that requiring success authentication to be requested.
 
 The whole example could look like this:
 
@@ -330,7 +330,7 @@ To create this file you can use available web-tools like [JWK creator](https://r
 
 ### JWT Auth GraphQL Configuration
 
-To use JWT you should first include JWKS file generated from [Prerequisites](#prerequisites) with the help of [`@link` directive](/docs/directives.md#jwks).
+To use JWT you should first include JWKS file generated from [Prerequisites](#prerequisites) with the help of [`@link` directive](/docs/directives/link.md#jwks).
 
 We can use that file as an example for it:
 
@@ -349,7 +349,7 @@ We can use that file as an example for it:
 }
 ```
 
-After adding `@link` you can use the [`@protected` directive](/docs/directives.md#protected-directive) to mark the fields that requiring success authentication to be requested.
+After adding `@link` you can use the [`@protected` directive](/docs/directives/protected.md) to mark the fields that requiring success authentication to be requested.
 
 The whole example could look like this:
 

docs/cli.md

@@ -430,9 +430,9 @@ preset:
    }
    ```
 
-2. **consolidateURL:** The setting identifies the most common base URL among multiple REST endpoints and uses this URL in the [upstream](directives.md#upstream-directive) directive. It takes a threshold value between 0.0 and 1.0 to determine the most common endpoint. The default is `0.5`.
+2. **consolidateURL:** The setting identifies the most common base URL among multiple REST endpoints and uses this URL in the [upstream](/docs/directives/upstream.md) directive. It takes a threshold value between 0.0 and 1.0 to determine the most common endpoint. The default is `0.5`.
 
-   For example, if the `Query` type has three base URLs, using the `consolidateURL` setting with a `0.5` threshold will pick the base URL that is used in more than 50% of the [http](directives.md#http-directive) directives, `http://jsonplaceholder.typicode.com`, and add it to the upstream, cleaning the base URLs from the `Query` type.
+   For example, if the `Query` type has three base URLs, using the `consolidateURL` setting with a `0.5` threshold will pick the base URL that is used in more than 50% of the [http](/docs/directives/http.md) directives, `http://jsonplaceholder.typicode.com`, and add it to the upstream, cleaning the base URLs from the `Query` type.
 
    ```graphql showLineNumbers
    schema

docs/client-tuning.md

@@ -50,7 +50,7 @@ Connection pooling mitigates these issues by reusing existing connections for re
 
 ## Tuning HTTP Client
 
-Tailcall uses connection pooling by default and sets up with default tuning suitable for most use cases. You might need to further tune the HTTP client to improve your application's performance. Tailcall DSL provides a directive named [`@upstream`](/docs/directives.md#upstream-directive) for this purpose.
+Tailcall uses connection pooling by default and sets up with default tuning suitable for most use cases. You might need to further tune the HTTP client to improve your application's performance. Tailcall DSL provides a directive named [`@upstream`](/docs/directives/upstream.md) for this purpose.
 
 :::note
 Connection pooling optimizes HTTP/1. Since HTTP/2 and HTTP/3 support multiplexing, pooling enabled does not noticeably affect performance.

docs/config-generation.md

@@ -697,9 +697,9 @@ This setting merges types in the configuration that satisfy the threshold criter
 
 ### consolidateURL
 
-The setting identifies the most common base URL among multiple REST endpoints and uses this URL in the [upstream](directives.md#upstream-directive) directive. It takes a threshold value between 0.0 and 1.0 to determine the most common endpoint. The default is `0.5`.
+The setting identifies the most common base URL among multiple REST endpoints and uses this URL in the [upstream](/docs/directives/upstream.md) directive. It takes a threshold value between 0.0 and 1.0 to determine the most common endpoint. The default is `0.5`.
 
-For example, if the `Query` type has three base URLs, using the `consolidateURL` setting with a `0.5` threshold will pick the base URL that is used in more than 50% of the [http](directives.md#http-directive) directives, `http://jsonplaceholder.typicode.com`, and add it to the upstream, cleaning the base URLs from the `Query` type.
+For example, if the `Query` type has three base URLs, using the `consolidateURL` setting with a `0.5` threshold will pick the base URL that is used in more than 50% of the [http](/docs/directives/http.md) directives, `http://jsonplaceholder.typicode.com`, and add it to the upstream, cleaning the base URLs from the `Query` type.
 
 ```graphql showLineNumbers
 schema
@@ -950,7 +950,7 @@ When setting up your configuration file for GraphQL generation with Tailcall, co
     </TabItem>
     </Tabs>
 
-2. **[Consolidate URL](config-generation.md#consolidateurl)**: Identifies the most common base URL among multiple REST endpoints and uses it in the [@upstream](directives.md#upstream-directive) directive. Set a threshold (0.0 to 1.0) to determine when to consolidate URLs. Recommended threshold is anything above `0.5`.
+2. **[Consolidate URL](config-generation.md#consolidateurl)**: Identifies the most common base URL among multiple REST endpoints and uses it in the [@upstream](/docs/directives/upstream.md) directive. Set a threshold (0.0 to 1.0) to determine when to consolidate URLs. Recommended threshold is anything above `0.5`.
    <Tabs>
    <TabItem value="json" label="JSON">
    ```json showLineNumbers
@@ -1043,7 +1043,7 @@ curl:
 
 **Q. What if I have multiple REST endpoints with different base URLs?**
 
-**Answer:** Use the [consolidateURL](config-generation.md#consolidateurl) parameter to identify the most common base URL among multiple REST endpoints and it will automatically select the most common base url and add it to the [@upstream](directives.md#upstream-directive) directive. Here is an example:
+**Answer:** Use the [consolidateURL](config-generation.md#consolidateurl) parameter to identify the most common base URL among multiple REST endpoints and it will automatically select the most common base url and add it to the [@upstream](/docs/directives/upstream.md) directive. Here is an example:
 
   <Tabs>
   <TabItem value="json" label="JSON">