migrate links to directives

docs/auth.md

@@ -49,7 +49,7 @@ 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](./config/links.md) connect multiple authentication files as you need for different provides. To connect it use either [`Htpasswd`](./config/links.md#htpasswd) or [`Jwks`](./config/links.md#jwks) link type
+1. With the help of [`links` config](./config/links.md) connect multiple authentication files as you need for different provides. To connect it use either [`Htpasswd`](./config/links.md#htpasswd) or [`Jwks`](./config/links.md#jwks) link type
 2. Mark that some type of field requires authentication to be fetched with the help of [`@protected` directive](./directives/protected.md)
 
 Your config could look like this now:
@@ -287,15 +287,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](./config/links.md#htpasswd).
+To use Basic Auth you should first include htpasswd file generated from [Prerequisites](#prerequisites) with the help of [`links` config](./config/links.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](./directives/protected.md) to mark the fields that requiring success authentication to be requested.
+After adding `links` you can use the [`@protected` directive](./directives/protected.md) to mark the fields that requiring success authentication to be requested.
 
 The whole example could look like this:
 
@@ -384,7 +384,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](./config/links.md#jwks).
+To use JWT you should first include JWKS file generated from [Prerequisites](#prerequisites) with the help of [`links` config](./config/links.md#jwks).
 
 We can use that file as an example for it:
 
@@ -403,7 +403,7 @@ We can use that file as an example for it:
 }
 ```
 
-After adding `@link` you can use the [`@protected` directive](./directives/protected.md) to mark the fields that requiring success authentication to be requested.
+After adding `links` you can use the [`@protected` directive](./directives/protected.md) to mark the fields that requiring success authentication to be requested.
 
 The whole example could look like this:
 

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`](./config/upstream.md) 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 configuration named [`upstream`](./config/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/directives/grpc.md

@@ -88,7 +88,7 @@ message UserGetReply {
 It is mandatory to have a package name in a protobuf file.
 :::
 
-Linking this file within a GraphQL schema is facilitated by the `@link` directive, as shown below:
+Linking this file within a GraphQL schema is facilitated by the `links` config, as shown below:
 
 ```yaml
 links:

docs/getting-started.mdx

@@ -174,7 +174,7 @@ type Post {
 }
 ```
 
-The above file is a standard `.graphQL` file, with some minor additions such as `@upstream` and `@http` directives. Basically we specify the GraphQL schema and how to resolve that GraphQL schema in the same file, without having to write any code!
+The above file is a standard `.graphQL` file, with some minor additions such as `@http` directives. Basically we specify the GraphQL schema and how to resolve that GraphQL schema in the same file, without having to write any code!
 
 ## Starting the GraphQL server
 

docs/grpc.md

@@ -135,7 +135,7 @@ upstream:
   httpCache: 42
 ```
 
-To specify the protobuf file to read types from, use the `@link` directive with the type `Protobuf` on the schema. `id` is an important part of the definition that will be used by the `@grpc` directive later
+To specify the protobuf file to read types from, use the `links` config with the type `Protobuf` on the schema. `id` is an important part of the definition that will be used by the `@grpc` directive later
 
 ```yaml
 links:

docs/http-cache.md

@@ -11,7 +11,7 @@ HTTP Caching in Tailcall is designed to enhance performance and minimize the fre
 
 HTTP Caching involves saving copies of HTTP responses to serve identical future requests directly from the cache, bypassing the need for new API calls. This reduces latency, conserves bandwidth, and alleviates the load on upstream services by utilizing a cache keyed by request URLs and headers.
 
-By default, HTTP caching is turned off in Tailcall. Enabling it requires setting the `httpCache` parameter to integer value which is greater than 0 in the `@upstream` configuration. Tailcall employs a in-memory _Least_Recently_Used_ (LRU) cache mechanism to manage stored responses, adhering to upstream-provided caching directives like `Cache-Control` to optimize the caching process and minimize redundant upstream API requests.
+By default, HTTP caching is turned off in Tailcall. Enabling it requires setting the `httpCache` parameter to integer value which is greater than 0 in the `upstream` configuration. Tailcall employs a in-memory _Least_Recently_Used_ (LRU) cache mechanism to manage stored responses, adhering to upstream-provided caching directives like `Cache-Control` to optimize the caching process and minimize redundant upstream API requests.
 
 ### Enabling HTTP Caching
 

docs/playground.md

@@ -1,14 +1,14 @@
 ---
 title: GraphQL Playground
-description: "Explore and test server configurations with the @server directive's showcase feature in a controlled environment. Ideal for quick experimentation and learning with dynamic GraphQL schema configurations. Not recommended for production due to performance and security considerations."
+description: "Explore and test server configuration showcase feature in a controlled environment. Ideal for quick experimentation and learning with dynamic GraphQL schema configurations. Not recommended for production due to performance and security considerations."
 slug: graphql-playground-guide
 sidebar_label: GraphQL Playground
 ---
 
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-The `@server` directive's `showcase` option allows for hands-on experimentation with server configurations in a controlled environment. This feature simplifies the process of exploring and testing different settings. This enables experimenting with random configurations hosted, without the need to restart the server or affect existing setups.
+The `showcase` option of server configuration allows for hands-on experimentation with server configurations in a controlled environment. This feature simplifies the process of exploring and testing different settings. This enables experimenting with random configurations hosted, without the need to restart the server or affect existing setups.
 
 #### Example Usage
 

docs/rest.md

@@ -81,7 +81,7 @@ to know more about the `@rest` directive, please refer to the [Tailcall GraphQL
 
 ### Step 3: Link the operation to the main config file
 
-checkout the `@link` directive in the config snippet below to link the operation file. This step is crucial to make the REST endpoint available.
+checkout the `links` option in the config snippet below to link the operation file. This step is crucial to make the REST endpoint available.
 
 ```yaml
 links:

graphql/graphql.md

@@ -257,7 +257,6 @@ type Query {
 
 In this example:
 We have used the `@http` directive to attach resolvers to the `post` field in the `Query`.
-and `@upstream` directive to define the base URL for the upstream server.
 
 This configuration is enough for starting a GraphQL server using Tailcall. You can start the server using the [`start`](/docs/tailcall-graphql-cli/#start) command.