From 2c6cf241a5c4a6730f1b366f525232dac7fbf48b Mon Sep 17 00:00:00 2001 From: tusharmath Date: Sat, 16 Mar 2024 05:59:07 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20tailcall?= =?UTF-8?q?hq/tailcallhq.github.io@7b002f4c64fe4725d3b3df097c0d287790c2934?= =?UTF-8?q?9=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 404.html | 4 +- about/index.html | 4 +- assets/js/60dd606e.22956c6c.js | 1 + assets/js/60dd606e.b673086d.js | 1 - assets/js/935f2afb.4af54c00.js | 1 + assets/js/935f2afb.fb3e3874.js | 1 - assets/js/c362a4a2.4bf5489e.js | 1 + assets/js/c362a4a2.b9de0a1e.js | 1 - assets/js/d3291ccc.bbe38708.js | 1 - assets/js/d3291ccc.d4c68aee.js | 1 + .../js/{main.be1350be.js => main.41008d48.js} | 4 +- ...CENSE.txt => main.41008d48.js.LICENSE.txt} | 0 ...n.e00519c4.js => runtime~main.25dce196.js} | 2 +- contact/index.html | 4 +- docs/getting_started/configuration/index.html | 6 +- docs/getting_started/execute/index.html | 6 +- docs/getting_started/index.html | 6 +- docs/getting_started/launch/index.html | 6 +- docs/guides/apollo-studio/index.html | 6 +- docs/guides/cli/index.html | 6 +- docs/guides/client-tuning/index.html | 6 +- docs/guides/context/index.html | 6 +- docs/guides/conventions/index.html | 6 +- docs/guides/environment-variables/index.html | 6 +- docs/guides/execution-strategy/index.html | 6 +- docs/guides/grpc/index.html | 6 +- docs/guides/http-cache/index.html | 6 +- docs/guides/http-filters/index.html | 6 +- docs/guides/logging/index.html | 8 +-- docs/guides/n+1/index.html | 70 +++++++------------ docs/guides/playground/index.html | 8 +-- docs/guides/scalar/index.html | 6 +- docs/guides/tailcall-on-aws/index.html | 6 +- docs/guides/watch-mode/index.html | 6 +- docs/index.html | 6 +- docs/operators/add-field/index.html | 6 +- docs/operators/cache/index.html | 6 +- docs/operators/call/index.html | 6 +- docs/operators/const/index.html | 6 +- docs/operators/graphql/index.html | 6 +- docs/operators/grpc/index.html | 6 +- docs/operators/http/index.html | 6 +- docs/operators/index.html | 6 +- docs/operators/link/index.html | 6 +- docs/operators/modify/index.html | 6 +- docs/operators/omit/index.html | 6 +- docs/operators/server/index.html | 6 +- docs/operators/telemetry/index.html | 6 +- docs/operators/upstream/index.html | 8 +-- enterprise/index.html | 4 +- index.html | 4 +- lunr-index-1710488048374.json | 1 - lunr-index-1710568711893.json | 1 + lunr-index.json | 2 +- search-doc-1710488048374.json | 1 - search-doc-1710568711893.json | 1 + search-doc.json | 2 +- 57 files changed, 153 insertions(+), 169 deletions(-) create mode 100644 assets/js/60dd606e.22956c6c.js delete mode 100644 assets/js/60dd606e.b673086d.js create mode 100644 assets/js/935f2afb.4af54c00.js delete mode 100644 assets/js/935f2afb.fb3e3874.js create mode 100644 assets/js/c362a4a2.4bf5489e.js delete mode 100644 assets/js/c362a4a2.b9de0a1e.js delete mode 100644 assets/js/d3291ccc.bbe38708.js create mode 100644 assets/js/d3291ccc.d4c68aee.js rename assets/js/{main.be1350be.js => main.41008d48.js} (99%) rename assets/js/{main.be1350be.js.LICENSE.txt => main.41008d48.js.LICENSE.txt} (100%) rename assets/js/{runtime~main.e00519c4.js => runtime~main.25dce196.js} (51%) delete mode 100644 lunr-index-1710488048374.json create mode 100644 lunr-index-1710568711893.json delete mode 100644 search-doc-1710488048374.json create mode 100644 search-doc-1710568711893.json diff --git a/404.html b/404.html index 17b2835c9e..f3be04fdb9 100644 --- a/404.html +++ b/404.html @@ -13,8 +13,8 @@ - - + +
Skip to main content

Installation

You can install the latest version -

, by using NPM.

NPM​

  1. diff --git a/docs/getting_started/launch/index.html b/docs/getting_started/launch/index.html index cf5af8223b..14ce2c142f 100644 --- a/docs/getting_started/launch/index.html +++ b/docs/getting_started/launch/index.html @@ -13,14 +13,14 @@ - - + +

    Launch

    Now, run the following command to start the server with the full path to the file that you created earlier.

    + Star

    Launch

    Now, run the following command to start the server with the full path to the file that you created earlier.

    tailcall start ./jsonplaceholder.graphql

    If the command succeeds, you should see logs like the following below.

     🚀 Tailcall launched at [0.0.0.0:8000]
     🌍 Playground: http://0.0.0.0:8000
    diff --git a/docs/guides/apollo-studio/index.html b/docs/guides/apollo-studio/index.html index ef658c171f..595a4d7c30 100644 --- a/docs/guides/apollo-studio/index.html +++ b/docs/guides/apollo-studio/index.html @@ -13,14 +13,14 @@ - - + +

    Apollo Studio

    This guide illustrates how to configure tailcall to send usage metrics to Apollo Studio.

    + Star

    Apollo Studio

    This guide illustrates how to configure tailcall to send usage metrics to Apollo Studio.

    Creating a monolith graph​

    1. diff --git a/docs/guides/cli/index.html b/docs/guides/cli/index.html index 3ba4d5af17..b33301787f 100644 --- a/docs/guides/cli/index.html +++ b/docs/guides/cli/index.html @@ -13,14 +13,14 @@ - - + +

      CLI

      The TailCall CLI (Command Line Interface) is an essential part of the TailCall toolkit. It allows developers to manage and optimize GraphQL configurations directly from the command line. Each command within the CLI handles a specific aspect of GraphQL composition. Below, you'll find a detailed overview of each command, along with its options and usage examples.

      + Star

      CLI

      The TailCall CLI (Command Line Interface) is an essential part of the TailCall toolkit. It allows developers to manage and optimize GraphQL configurations directly from the command line. Each command within the CLI handles a specific aspect of GraphQL composition. Below, you'll find a detailed overview of each command, along with its options and usage examples.

      check​

      The check command validates a composition spec. Notably, this command can detect potential N+1 issues. To use the check command, follow this format:

      tailcall check [options] <file>...
      diff --git a/docs/guides/client-tuning/index.html b/docs/guides/client-tuning/index.html index e9c01e18d8..633580a1d2 100644 --- a/docs/guides/client-tuning/index.html +++ b/docs/guides/client-tuning/index.html @@ -13,14 +13,14 @@ - - + +

      Client Tuning

      HTTP (Hypertext Transfer Protocol)​

      + Star

      Client Tuning

      HTTP (Hypertext Transfer Protocol)​

      HTTP, the most widely used protocol for communication between clients and servers, carries your request to the server and then brings back the data to your client. TCP forms the foundation of HTTP.

      HTTP Versions: 1.x, 2, and 3​

      Each version has enhanced HTTP's flexibility and performance.

      diff --git a/docs/guides/context/index.html b/docs/guides/context/index.html index abae8fd5bb..0975da1fb5 100644 --- a/docs/guides/context/index.html +++ b/docs/guides/context/index.html @@ -13,14 +13,14 @@ - - + +

      Context Overview

      Within Tailcall, Context is a pivotal component that allows for dynamic retrieval of values during the resolution of fields for a given type within the schema.

      + Star

      Context Overview

      Within Tailcall, Context is a pivotal component that allows for dynamic retrieval of values during the resolution of fields for a given type within the schema.

      Schema Definition​

      type Context = {
        args: Map<string, JSON>
        value: JSON
        env: Map<string, string>
        vars: Map<string, string>
        headers: Map<string, string>
      }

      Context operates by storing values as key-value pairs, which can be accessed through mustache template syntax.

      diff --git a/docs/guides/conventions/index.html b/docs/guides/conventions/index.html index 0926f18234..64607752db 100644 --- a/docs/guides/conventions/index.html +++ b/docs/guides/conventions/index.html @@ -13,14 +13,14 @@ - - + +

      Naming Conventions

      General Naming Principles​

      + Star

      Naming Conventions

      General Naming Principles​

      1. Consistency is Key: Ensure that naming conventions are uniform across your entire schema to maintain clarity and consistency.
      2. Descriptive Over Generic: Opt for descriptive, specific names rather than broad, generic ones to avoid ambiguity.
        3. diff --git a/docs/guides/environment-variables/index.html b/docs/guides/environment-variables/index.html index f74046c26c..9c5fc153c0 100644 --- a/docs/guides/environment-variables/index.html +++ b/docs/guides/environment-variables/index.html @@ -13,14 +13,14 @@ - - + +

        Environment Variables

        Environment variables are key-value pairs stored in our operating systems. Most of them come by default, and we can also create our own. They store information used by our operating system or other programs. For example, the PATH variable stores a list of directories the operating system searches when we run a command in the terminal. The HOME variable stores the path to our home directory.

        + Star

        Environment Variables

        Environment variables are key-value pairs stored in our operating systems. Most of them come by default, and we can also create our own. They store information used by our operating system or other programs. For example, the PATH variable stores a list of directories the operating system searches when we run a command in the terminal. The HOME variable stores the path to our home directory.

        These variables also serve in software development for storing configuration values.

        Need for Environment Variables​

        Applications rely on external tools, authentication methods, and configurations. For proper functioning, our code needs to access these values.

        diff --git a/docs/guides/execution-strategy/index.html b/docs/guides/execution-strategy/index.html index d481c1a037..5910cabf38 100644 --- a/docs/guides/execution-strategy/index.html +++ b/docs/guides/execution-strategy/index.html @@ -13,14 +13,14 @@ - - + +

        Sequencing & Parallelism

        Building data access layers often involves meticulous orchestration of API calls, but Tailcall simplifies this process. By analyzing your defined schema, it automatically determines the optimal execution strategy, deciding when to sequence calls and when to run them in parallel. This allows you to focus on your core application logic, while Tailcall handles the optimization seamlessly. Now, let's get into some real-world examples to illustrate its functionality.

        + Star

        Sequencing & Parallelism

        Building data access layers often involves meticulous orchestration of API calls, but Tailcall simplifies this process. By analyzing your defined schema, it automatically determines the optimal execution strategy, deciding when to sequence calls and when to run them in parallel. This allows you to focus on your core application logic, while Tailcall handles the optimization seamlessly. Now, let's get into some real-world examples to illustrate its functionality.

        Examples​

        Example 1: Fetching a Specific User and Their Posts​

        Imagine you're building a blog and want to display a specific user's profile page containing their information and all their posts.

        diff --git a/docs/guides/grpc/index.html b/docs/guides/grpc/index.html index d805a02762..3baa772f59 100644 --- a/docs/guides/grpc/index.html +++ b/docs/guides/grpc/index.html @@ -13,14 +13,14 @@ - - + +

        GraphQL on gRPC

        In this guide, we will set up a simple gRPC service and use it inside Tailcall's config to fetch some of the data provided by the service. This way Tailcall can provide a single GraphQL interface wrapping any number of gRPC services.

        + Star

        GraphQL on gRPC

        In this guide, we will set up a simple gRPC service and use it inside Tailcall's config to fetch some of the data provided by the service. This way Tailcall can provide a single GraphQL interface wrapping any number of gRPC services.

        What is gRPC?​

        This guide assumes a basic familiarity with gRPC. It is a high-performance framework created by Google for remote procedure calls (RPCs). Its key features include:

          diff --git a/docs/guides/http-cache/index.html b/docs/guides/http-cache/index.html index 54205968f7..f9529594db 100644 --- a/docs/guides/http-cache/index.html +++ b/docs/guides/http-cache/index.html @@ -13,14 +13,14 @@ - - + +

          Http Cache

          HTTP Caching in Tailcall is designed to enhance performance and minimize the frequency of requests to upstream services by caching HTTP responses. This guide explains the concept, benefits, and how to effectively implement HTTP caching within Tailcall.

          + Star

          Http Cache

          HTTP Caching in Tailcall is designed to enhance performance and minimize the frequency of requests to upstream services by caching HTTP responses. This guide explains the concept, benefits, and how to effectively implement HTTP caching within Tailcall.

          Understanding HTTP Caching​

          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 true 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.

          diff --git a/docs/guides/http-filters/index.html b/docs/guides/http-filters/index.html index 5bd26d6d0c..b575b612fb 100644 --- a/docs/guides/http-filters/index.html +++ b/docs/guides/http-filters/index.html @@ -13,14 +13,14 @@ - - + +

          HTTP Filters

          Tailcall provides a light-weight JS runtime to modify requests and resolve with custom responses. +

          Star

          HTTP Filters

          Tailcall provides a light-weight JS runtime to modify requests and resolve with custom responses. The runtime is not a full-fledged Node.js environment and has no access to the file system or the network. It is designed to be used for simple request/response modifications.

          Getting Started​

          To leverage this functionality, a JavaScript function named onRequest must be created in a worker.js file. This function serves as middleware, allowing for the interception and modification of the request. Here is a simple example of a worker.js file that logs the request and returns the original request without any modifications.

          diff --git a/docs/guides/logging/index.html b/docs/guides/logging/index.html index 8075a4e547..659d1894d7 100644 --- a/docs/guides/logging/index.html +++ b/docs/guides/logging/index.html @@ -13,14 +13,14 @@ - - + +

          Logging

          Logging acts as an essential tool for obtaining insights into code execution and addressing software development challenges. You can configure the verbosity of logs via log levels. Use TAILCALL_LOG_LEVEL or TC_LOG_LEVEL environment variables to set the application's log level. The available log levels include:

          + Star

          Logging

          Logging acts as an essential tool for obtaining insights into code execution and addressing software development challenges. You can configure the verbosity of logs via log levels. Use TAILCALL_LOG_LEVEL or TC_LOG_LEVEL environment variables to set the application's log level. The available log levels include:

          error​

          This is the highest severity level. It indicates a critical issue that may lead to the failure of the program or a part of it.

          TAILCALL_LOG_LEVEL=error tailcall <COMMAND>
          # or
          TC_LOG_LEVEL=error tailcall <COMMAND>
          @@ -42,6 +42,6 @@

          off
          info

          The default log level is info.

          Log levels are hierarchical, meaning if you set the log level to a specific level, it includes all the levels above it. For example, setting the log level to info will include logs at the info, warn, and error levels, but exclude debug and trace logs.

          Hierarchy of Log Levels

          -
          info

          You can specify log levels in either uppercase or lowercase; both yield the same result. For example, TAILCALL_LOG_LEVEL=DEBUG and TAILCALL_LOG_LEVEL=debug are same.

          +
          info

          You can specify log levels in either uppercase or lowercase; both yield the same result. For example, TAILCALL_LOG_LEVEL=DEBUG and TAILCALL_LOG_LEVEL=debug are same.

          \ No newline at end of file diff --git a/docs/guides/n+1/index.html b/docs/guides/n+1/index.html index 567a1f8faf..4a20770684 100644 --- a/docs/guides/n+1/index.html +++ b/docs/guides/n+1/index.html @@ -3,7 +3,7 @@ -Tackling N + 1 | Tailcall +N+1 Problem | Tailcall @@ -13,55 +13,39 @@ - - + +

          Tackling N + 1

          The N+1 problem is a pervasive and critical issue in application development that occurs when an application ends up issuing a large number of downstream requests, for a single request from upstream. Let's understand with an example:

          -

          Scenario​

          -

          Consider we're developing a feature that involves consuming data from the JSON Placeholder API. The feature requires fetching posts and the details of the authors of these posts.

          -

          Here's an illustration of a typical implementation:

          + Star

          N+1 Problem

          The N+1 problem hampers application performance, manifesting when an app issues numerous requests downstream in response to a single upstream request. To grasp this, consider the following example:

          +

          Example Scenario​

          +

          Imagine we're enhancing a feature that involves fetching data from the [JSON Placeholder API], requiring posts and their authors' details.

          Fetching Posts​

          -

          First, we send a request to retrieve all posts:

          -
          curl https://jsonplaceholder.typicode.com/posts
          -

          The above request fetches a list of posts from the API, each of which includes a userId field indicating the author of the post.

          -

          Fetching Users​

          -

          Then, for each post, we need to get the author's details. A request for a specific user might look like this:

          -
          curl https://jsonplaceholder.typicode.com/users/1
          -

          If we received 100 posts from our first request, we would then make 100 more requests to get each post's author details, resulting in a total of 101 requests.

          -

          The N+1 problem, illustrated with the JSON Placeholder API, occurs when one API request triggers more. For example, fetching 100 posts then requesting each post's author details results in 101 requests.

          -
          info

          In real-world applications featuring thousands of posts and users, the problem becomes more severe. Each user request can generate hundreds or thousands of server requests, straining server resources and resulting in slower response times, increased server costs, and a diminished user experience. This issue may even cause server downtime due to the overwhelming number of requests, affecting service availability. Thus, addressing the N+1 problem during the design and development phases of applications that make extensive API requests is essential. We will explore solutions to this issue in the following sections.

          -

          Using the CLI​

          -

          The TailCall CLI serves as a powerful tool for developers, identifying N+1 issues in GraphQL applications even before making any requests or publishing configurations in production. This proactive approach enables the mitigation of potential issues from the development stage.

          -

          Before diving into the usage, ensure you have familiarized yourself with the basics of the TailCall CLI. If you haven't already, please refer to the installation guide, which will walk you through the setup process and help you understand the key commands.

          -

          Jsonplaceholder Example​

          -

          Here is a sample .graphql file that we'll be examining:

          -
          schema
            @upstream(
              baseURL: "http://jsonplaceholder.typicode.com"
            ) {
            query: Query
          }

          type Query {
            posts: [Post] @http(path: "/posts")
          }

          type User {
            id: Int!
            name: String!
            username: String!
            email: String!
            phone: String
            website: String
          }

          type Post {
            id: Int!
            userId: Int!
            title: String!
            body: String!
            user: User @http(path: "/users/{{value.userId}}")
          }
          -

          This schema enables clients to retrieve a list of posts, each including its associated user data. Yet, in its present form, it's affected by the N+1 problem: fetching each post necessitates a separate request for its associated user data.

          -

          The following section will show how to detect this issue with the TailCall CLI.

          -

          Running the TailCall CLI​

          -

          With the check command, TailCall CLI can assist you in identifying potential N+1 issues in a GraphQL file:

          -
          tailcall check ./jsonplaceholder.graphql
          INFO File read: ./examples/jsonplaceholder.graphql ... ok
          INFO Config ./examples/jsonplaceholder.graphql ... ok
          INFO N + 1 detected: 1
          -

          The N + 1: 1 line tells you that the TailCall CLI has detected one potential N+1 issue.

          -

          For a deeper understanding of these issues, you can use the --n-plus-one-queries parameter:

          -
          tailcall check  ./jsonplaceholder.graphql --n-plus-one-queries
          INFO File read: ./examples/jsonplaceholder.graphql ... ok
          INFO Config ./examples/jsonplaceholder.graphql ... ok
          INFO N + 1 detected: 1
          query { posts { user } }
          -

          This parameter uncovers the minimal query that can trigger an N+1 problem. In the above case, query { posts { user } }, represents the minimal query that could lead to an N+1 problem. It illustrates that within the posts query, each post is triggering an extra request to fetch its associated user data.

          -

          Solving Using Batching​

          -

          It's an effective technique to group similar requests into one, greatly reducing the number of server calls. The TailCall CLI provides this capability to address the typical N+1 issue that arises in GraphQL.

          -

          To tap into this feature, edit the @http directive on Post.user in your GraphQL schema as follows:

          -
          type Post {
            id: Int!
            userId: Int!
            title: String!
            body: String!
            user: User
              @http(
                path: "/users"
                query: [{key: "id", value: "{{value.userId}}"}]
                batchKey: ["id"]
              )
          }
          -

          The described changes introduce two significant tweaks to the @http directive and incorporate the batchKey configuration:

          +

          Initially, we request all posts:

          +
          curl https::/jsonplaceholder.typicode.com/posts
          [
            {
              "userId": 1,
              "id": 1,
              "title": "Creating Solutions for Challenges",
              "body": "We anticipate and understand challenges, creating solutions while considering exceptions and criticisms."
            },
            {
              "userId": 1,
              "id": 2,
              "title": "Understanding Identity",
              "body": "Life's essence, measured through time, presents pains and joys. We find solace in the mundane, seeking meaning beyond the visible."
            }
          ]
          +

          This command retrieves posts from the API, with each post containing a userId field denoting its author.

          +

          Fetching Authors​

          +

          Subsequently, we fetch details for each post's author, exemplified by:

          +
          curl https://jsonplaceholder.typicode.com/users/1
          {
            "id": 1,
            "name": "Leanne Graham",
            "username": "Bret",
            "email": "Sincere@april.biz",
            "address": {
              "street": "Kulas Light",
              "suite": "Apt. 556",
              "city": "Gwenborough",
              "zipcode": "92998-3874",
              "geo": {
                "lat": "-37.3159",
                "lng": "81.1496"
              }
            },
            "phone": "1-770-736-8031 x56442",
            "website": "hildegard.org",
            "company": {
              "name": "Romaguera-Crona",
              "catchPhrase": "Multi-layered client-server neural-net",
              "bs": "harness real-time e-markets"
            }
          }
          +

          For 100 posts, this leads to 100 additional requests to obtain author details, totaling 101 requests.

          +

          The N+1 issue with the JSON Placeholder API arises when fetching 100 posts prompts 100 separate requests for author details, cumulating to 101 requests.

          +
          info

          This issue escalates in real-life scenarios with thousands of posts and users, multiplying the server requests, which strains resources, hikes server costs, slows response times, and can even cause server downtime. Addressing the N+1 issue during application design and development is crucial for efficient API usage. We will examine solutions to mitigate this problem.

          +

          Initial Configuration with TailCall CLI​

          +

          Before diving into solutions, it's insightful to see the N+1 problem in action using the TailCall CLI with the initial .graphql configuration:

          +
          ❯ tailcall start ./examples/jsonplaceholder.graphql
            INFO File read: ./examples/jsonplaceholder.graphql ... ok
            INFO N + 1 detected: 1
            INFO 🚀 Tailcall launched at [0.0.0.0:8000] over HTTP/1.1
            INFO 🌍 Playground: http://127.0.0.1:8000
            INFO GET http://jsonplaceholder.typicode.com/posts HTTP/1.1
            INFO GET http://jsonplaceholder.typicode.com/users/8 HTTP/1.1
            ...
            INFO GET http://jsonplaceholder.typicode.com/users/10 HTTP/1.1
          +

          These logs demonstrate the sequence of requests made to fetch posts and then individual users, highlighting the N+1 problem in real-time.

          +

          Optimizing with Batching​

          +

          After incorporating the batchKey optimization, let's observe the transformed behavior through the TailCall CLI:

          +
          ❯ tailcall start ./examples/jsonplaceholder.graphql
            INFO File read: ./examples/jsonplaceholder.graphql ... ok
            INFO N + 1 detected: 0
            INFO 🚀 Tailcall launched at [0.0.0.0:8000] over HTTP/1.1
            INFO 🌍 Playground: http://127.0.0.1:8000
            INFO GET http://jsonplaceholder.typicode.com/posts HTTP/1.1
            INFO GET http://jsonplaceholder.typicode.com/users?id=1&id=10&id=2&id=3&id=4&id=5&id=6&id=7&id=8&id=9 HTTP/1.1
          +

          The Impact of Optimization​

          +

          The logs now reveal a substantial reduction in requests. Initially, fetching 100 posts would lead to an additional 100 requests to gather author details, totaling 101 requests. However, after applying batching with the batchKey, we observe two requests:

            -
          1. -

            query: [{key: "id", value: "{{value.userId}}"}]: In this configuration, the TailCall CLI generates a URL that aligns the user id with the userId from the parent Post. For a batch of posts, the CLI compiles a single URL, such as /users?id=1&id=2&id=3...id=10, consolidating the requests into one.

            -
            2. -
          2. -

            batchKey: ["id"]: This parameter instructs the system to convert the list of responses into a map internally, using the user's id as the unique key. In essence, it allows the system to differentiate each user value in the response list.

            -
            3. +
          3. A single request to fetch all posts.
            4. +
          4. A single consolidated request for all users involved in the posts, using query parameters to fetch multiple users in one go.
          -

          By using this approach, you can reduce the number of requests from 101 (for 100 posts plus one initial request for the post list) down to 2. This significant optimization effectively handles the N+1 problem, thereby enhancing your application's efficiency and user experience.

          +

          This optimization starkly contrasts the initial approach by reducing the number of server requests, thus minimizing server load, enhancing response times, and potentially lowering server costs. It demonstrates the effectiveness of addressing the N+1 problem through thoughtful schema design and the use of advanced tooling like the TailCall CLI, which facilitates a more efficient data fetching strategy that's crucial for scalable and performant web applications.

        \ No newline at end of file diff --git a/docs/guides/playground/index.html b/docs/guides/playground/index.html index faf3ccc6b9..baec3eeebb 100644 --- a/docs/guides/playground/index.html +++ b/docs/guides/playground/index.html @@ -13,14 +13,14 @@ - - + +

        Playground

        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.

        + Star

        Playground

        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.

        Example Usage​

        schema @server(showcase: true, graphiql: true) {
          query: Query
        }

        type User {
          notId: Int
          notName: String
        }

        type Query {
          notUser: User
            @http(
              path: "/users/1"
              baseURL: "http://jsonplaceholder.typicode.com"
            )
        }

        To test it out, append /showcase/graphql?config=YOUR_CONFIG_URL to your GraphQL base URL when querying the data.

        @@ -31,6 +31,6 @@

        important

        Due to these concerns, this mode is not recommended for production environments.

        +
        important

        Due to these concerns, this mode is not recommended for production environments.

        \ No newline at end of file diff --git a/docs/guides/scalar/index.html b/docs/guides/scalar/index.html index 8d9d78f822..78ed44e9c4 100644 --- a/docs/guides/scalar/index.html +++ b/docs/guides/scalar/index.html @@ -13,14 +13,14 @@ - - + +

        Scalars

        The GraphQL specification includes default scalar types Int, Float, String, Boolean, and ID. Although these scalars cover the majority of use cases, some applications need to support other atomic data types such as Date or an Email. +

        Star

        Scalars

        The GraphQL specification includes default scalar types Int, Float, String, Boolean, and ID. Although these scalars cover the majority of use cases, some applications need to support other atomic data types such as Date or an Email. Tailcall provides these predefined scalars, with built-in validations, eliminating the need for you to do so.

        Default Scalars​

        Here is a list of default scalars that are built into the GraphQL Spec:

        diff --git a/docs/guides/tailcall-on-aws/index.html b/docs/guides/tailcall-on-aws/index.html index f575b07db7..d3d2cdd1cf 100644 --- a/docs/guides/tailcall-on-aws/index.html +++ b/docs/guides/tailcall-on-aws/index.html @@ -13,14 +13,14 @@ - - + +

        Tailcall on AWS

        Tailcall can be hosted on AWS using Lambda and API Gateway using the tailcall-on-aws template.

        + Star

        Tailcall on AWS

        Tailcall can be hosted on AWS using Lambda and API Gateway using the tailcall-on-aws template.

        1. Install Terraform. The template uses Terraform to orchestrate the required AWS infrastructure, to spare you the time of setting it up by hand.
        2. Set the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_REGION environment variables. These are required by Terraform to be able to manage the resourced on AWS. More info here.
          3. diff --git a/docs/guides/watch-mode/index.html b/docs/guides/watch-mode/index.html index f918387bf4..002ff09027 100644 --- a/docs/guides/watch-mode/index.html +++ b/docs/guides/watch-mode/index.html @@ -13,14 +13,14 @@ - - + +

          Watch Mode

          Developers often find themselves in situations where they need to run a server in watch mode to streamline the development process. This guide will introduce you to entr, a versatile file-watcher tool, and how to run your server in watch mode with it. We'll also touch on the installation process and suggest some best practices to optimize your workflow.

          + Star

          Watch Mode

          Developers often find themselves in situations where they need to run a server in watch mode to streamline the development process. This guide will introduce you to entr, a versatile file-watcher tool, and how to run your server in watch mode with it. We'll also touch on the installation process and suggest some best practices to optimize your workflow.

          Use case​

          Running a server in watch mode offers a lot of key benefits: