Merge branch 'develop' into update-batch-key-logic

tailcallhq · Aug 12, 2024 · a54c92c · a54c92c
2 parents 24f1d34 + 977580b
commit a54c92c
Show file tree

Hide file tree

Showing 78 changed files with 3,957 additions and 394 deletions.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -10,6 +10,9 @@ on:
     branches: [develop]
     types: [opened, reopened, synchronize]
 
+permissions:
+  contents: write
+
 jobs:
   build-and-deploy:
     concurrency: ci-${{ github.ref }}
@@ -29,7 +32,7 @@ jobs:
       - name: Install and Build 🔧
         run: |
           npm install
-          npx prettier --check "**/*.{graphql,yml,json,md,sh,ts,tsx,js}"
+          npx prettier --check "**/*.{graphql,yml,json,md,sh,ts,tsx,js,css}"
           npm run build
 
       - name: Deploy 🚀
@@ -38,23 +41,26 @@ jobs:
         with:
           folder: build
 
-      - name: Get changed markdown files
-        id: changed-markdown-files
-        uses: tj-actions/changed-files@v44
-        with:
-          files: |
-            blog/**/*.{md,mdx}
-
       - name: Publish to Hashnode and Dev.to 📝
-        if: github.ref == 'refs/heads/develop' && steps.changed-markdown-files.outputs.any_changed == 'true'
         env:
           HASHNODE_PAT: ${{ secrets.HASHNODE_PAT }}
           HASHNODE_PUBLICATION_ID: ${{ secrets.HASHNODE_PUBLICATION_ID }}
-          CHANGED_FILES: ${{ steps.changed-markdown-files.outputs.all_changed_files }}
           DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY}}
           DEVTO_ORG_ID: ${{secrets.DEVTO_ORG_ID}}
           DEVTO_ORG_NAME: ${{secrets.DEVTO_ORG_NAME}}
         run: |
           cd ./publish-externals
           npm run generate
-          npx --yes tsx ./src/index.ts "$CHANGED_FILES"
+          if [ "$GITHUB_REF" == "refs/heads/develop" ]; then
+            npx --yes tsx ./src/index.ts --publish
+          else
+            npx --yes tsx ./src/index.ts
+          fi
+
+      - name: Commit and push changes (on develop)
+        if: github.event_name == 'push' && github.ref == 'refs/heads/develop'
+        uses: stefanzweifel/git-auto-commit-action@v5
+        with:
+          branch: develop
+          commit_author: Author <[email protected]>
+          commit_message: "[ci skip] update snapshot"
diff --git a/.github/workflows/convention.yml b/.github/workflows/convention.yml
@@ -0,0 +1,30 @@
+name: PR Title Validation
+
+on:
+  # pull_request_target is ok until we do not checkout and build external code
+  # TODO: maybe it is not required after all https://github.com/amannn/action-semantic-pull-request/issues/219
+  pull_request_target:
+    types: [opened, reopened, synchronize, edited]
+
+permissions:
+  pull-requests: read
+
+jobs:
+  title-check:
+    name: Check PR Title
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: PR Title
+        uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Bounty PR Title
+        if: contains(github.event.pull_request.labels.*.name, '🙋 Bounty claim')
+        uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          requireScope: true
+          scopes: \d+
diff --git a/.gitignore b/.gitignore
@@ -23,3 +23,4 @@ yarn-error.log*
 .idea/
 src/*/*.json
 .vscode/
+.gitpod.yml
diff --git a/blog/graphql-angular-clients-2024-07-20.md b/blog/graphql-angular-clients-2024-07-20.md
@@ -950,25 +950,31 @@ We've put together a complete set of working examples for everything we've cover
 
 ## Detailed Comparison Table
 
-| Method          | Bundle Size (minified + gzip)\* | Learning Curve | Caching Capabilities                    | Community Support | Additional Features                        |
-| --------------- | ------------------------------- | -------------- | --------------------------------------- | ----------------- | ------------------------------------------ |
-| Apollo Angular  | ~2kB                            | Moderate       | Extensive (InMemoryCache, customizable) | High              | State management, optimistic UI updates    |
-| Urql            | ~10.2 KB                        | Low            | Moderate (Document caching)             | Moderate          | Extensible architecture, lightweight       |
-| GraphQL-Request | Unknown                         | Low            | None (Minimal client)                   | Moderate          | Simplicity, works in Node and browsers     |
-| Axios           | ~13.2 KB                        | Low            | None (HTTP client only)                 | High              | Familiar HTTP handling, interceptors       |
-| Fetch API       | 0 KB (Browser built-in)         | Low            | None (Native API)                       | High              | No additional dependency, widely supported |
-
-(\*) Bundle sizes are approximate and may vary based on version and configuration. Values are culled from bundlephobia.com where available.
-
-### Notes:
-
-- **Apollo Angular**: Offers the most comprehensive feature set but comes with a larger bundle size and steeper learning curve.
-- **Urql**: Provides a good balance between features and bundle size, with a focus on simplicity.
-- **GraphQL-Request**: Minimal client ideal for simple use cases where advanced features aren't needed.
-- **Axios**: Not a GraphQL-specific solution, but familiar to many developers and versatile for various HTTP requests.
-- **Fetch API**: Native browser API, no additional bundle size, but requires more manual work for GraphQL operations.
-
-This table should help developers choose the right method based on their specific project needs, considering factors like bundle size, learning curve, caching capabilities, community support, and additional features.
+| Method           | Bundle Size (minified + gzip)\* | Learning Curve | Caching Capabilities                       | Community Support | Additional Features                                 |
+| ---------------- | ------------------------------- | -------------- | ------------------------------------------ | ----------------- | --------------------------------------------------- |
+| Apollo Angular¹  | 258 KB                          | Moderate       | Extensive (InMemoryCache, customizable)    | High              | State management, optimistic UI updates             |
+| Urql²            | 17 KB                           | Low            | Moderate (Document and normalized caching) | Moderate          | Extensible architecture, lightweight, plugin system |
+| GraphQL-Request³ | 58.6 KB                         | Low            | None (Minimal client)                      | Moderate          | Simplicity, works in Node and browsers              |
+| Axios⁴           | 24 KB                           | Low            | None (HTTP client only)                    | High              | Familiar HTTP handling, interceptors                |
+| Fetch API        | 0 KB (Browser built-in)         | Low            | None (Native API)                          | High              | No additional dependency, widely supported          |
+
+(\*) Bundle sizes are based on bundlejs.com calculations using the provided export statements, with minification and gzip compression applied.
+
+**Notes:**
+
+1. Apollo Angular's bundle size (258 KB gzipped) is significantly larger than other options, which may impact initial load times for applications.
+2. Urql offers a much smaller bundle size (17 KB gzipped) while still providing both document caching and normalized caching through its plugin architecture.
+3. GraphQL-Request, despite being a minimal client, has a larger bundle size (58.6 KB gzipped) than expected, which might be due to including the full GraphQL parser.
+4. Axios, a general-purpose HTTP client, has a moderate bundle size (24 KB gzipped) considering its feature set.
+5. The Fetch API remains the lightest option as it's built into modern browsers, but it lacks some conveniences provided by other libraries.
+6. Bundle sizes for critical path libraries can significantly impact performance. Consider lazy-loading or code-splitting strategies when using larger libraries like Apollo Angular.
+
+**Bundle Size References:**
+
+1. Apollo Angular: [bundlejs.com link](https://bundlejs.com/?q=apollo-angular%2Capollo-angular%2Fhttp%2C%40apollo%2Fclient%2Fcore&treeshake=%5B%7B+APOLLO_OPTIONS%2CApolloModule+%7D%5D%2C%5B%7B+HttpLink+%7D%5D%2C%5B%7B+InMemoryCache+%7D%5D)
+2. Urql: [bundlejs.com link](https://bundlejs.com/?q=urql%2C%40urql%2Fcore&treeshake=%5B%7B+createClient%2CProvider%2CuseQuery%2CuseMutation+%7D%5D%2C%5B%7B+cacheExchange%2CfetchExchange+%7D%5D)
+3. GraphQL-Request: [bundlejs.com link](https://bundlejs.com/?q=graphql-request&treeshake=%5B%7B+GraphQLClient%2Cgql+%7D%5D)
+4. Axios: [bundlejs.com link](https://bundlejs.com/?q=axios&treeshake=%5B%7B+default+as+axios+%7D%5D)
 
 ### Caching Capabilities
 

diff --git a/blog/graphql-schema-2024-07-11.md b/blog/graphql-schema-2024-07-11.md
@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 1
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall

diff --git a/blog/graphql-schema-part-2-1-2024-07-21.mdx b/blog/graphql-schema-part-2-1-2024-07-21.mdx
@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2.1
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall
@@ -14,14 +14,70 @@ slug: graphql-schema-part-2-1
 
 import Quiz from "../src/components/quiz/quiz.tsx"
 
-![GraphQL Schema Structure](../static/images/graphql/graphql-schema-structure.png)
+## What Do You Already Know? 🧠💫
 
-In our [previous post](/blog/graphql-schema), we learned scalable GraphQL schema is critical for building production-ready APIs that can evolve with your application's needs.
+<Quiz
+  title="GraphQL Schema Change"
+  questions={[
+    {
+      id: 1,
+      text: "Adding a new field to a GraphQL schema is generally a:",
+      options: ["Safe change", "Dangerous change", "Breaking change", "Requires deprecation"],
+      correctAnswer: 0,
+    },
+    {
+      id: 2,
+      text: "What is a potential issue when adding a new optional argument to a resolver?",
+      options: [
+        "It requires clients to update their queries",
+        "It can change the default behavior if not handled properly",
+        "It always breaks existing queries",
+        "It is not allowed in GraphQL",
+      ],
+      correctAnswer: 1,
+    },
+    {
+      id: 3,
+      text: "Which strategy can make adding a required argument safe?",
+      options: [
+        "Introducing a new field",
+        "Providing a default value",
+        "Deprecating the old argument",
+        "Using introspection queries",
+      ],
+      correctAnswer: 1,
+    },
+    {
+      id: 4,
+      text: "What is a common risk when adding a new type to an existing interface?",
+      options: [
+        "Clients will receive runtime errors if not properly type-checked",
+        "The schema becomes invalid",
+        "Existing types get overridden",
+        "It forces all clients to update immediately",
+      ],
+      correctAnswer: 0,
+    },
+    {
+      id: 5,
+      text: "What should clients implement to handle new union members?",
+      options: [
+        "Fallback UI components for unknown types",
+        "Always use non-null fields",
+        "Deprecation notices",
+        "Schema descriptions",
+      ],
+      correctAnswer: 0,
+    },
+  ]}
+/>
 
-In this post, we will dive deeper into how to **continuously** evolve your schema to meet your application's changing requirements without hard-coded versioning.
+In our [previous post](/blog/graphql-schema), we learned scalable GraphQL schema is critical for building production-ready APIs that can evolve with your application's needs.
 
 <!-- truncate -->
 
+In this post, we will dive deeper into how to **continuously** evolve your schema to meet your application's changing requirements without hard-coded versioning.
+
 ## Adding Without Breaking: The Art of Additive Changes
 
 You know that feeling when you're working on a project, and suddenly you realize your schema needs to change? Maybe you need to add a new field, modify an existing one, or even remove something entirely. It's enough to make any developer break out in a cold sweat, right?
@@ -272,64 +328,6 @@ switch (order.status) {
 }
 ```
 
-## Quiz Time! 🎉
-
-<Quiz
-  title="GraphQL Schema Change"
-  questions={[
-    {
-      id: 1,
-      text: "Adding a new field to a GraphQL schema is generally a:",
-      options: ["Safe change", "Dangerous change", "Breaking change", "Requires deprecation"],
-      correctAnswer: 0,
-    },
-    {
-      id: 2,
-      text: "What is a potential issue when adding a new optional argument to a resolver?",
-      options: [
-        "It requires clients to update their queries",
-        "It can change the default behavior if not handled properly",
-        "It always breaks existing queries",
-        "It is not allowed in GraphQL",
-      ],
-      correctAnswer: 1,
-    },
-    {
-      id: 3,
-      text: "Which strategy can make adding a required argument safe?",
-      options: [
-        "Introducing a new field",
-        "Providing a default value",
-        "Deprecating the old argument",
-        "Using introspection queries",
-      ],
-      correctAnswer: 1,
-    },
-    {
-      id: 4,
-      text: "What is a common risk when adding a new type to an existing interface?",
-      options: [
-        "Clients will receive runtime errors if not properly type-checked",
-        "The schema becomes invalid",
-        "Existing types get overridden",
-        "It forces all clients to update immediately",
-      ],
-      correctAnswer: 0,
-    },
-    {
-      id: 5,
-      text: "What should clients implement to handle new union members?",
-      options: [
-        "Fallback UI components for unknown types",
-        "Always use non-null fields",
-        "Deprecation notices",
-        "Schema descriptions",
-      ],
-      correctAnswer: 0,
-    },
-  ]}
-/>
-
 ## Conclusion
 
 Evolving a GraphQL schema through additive changes allows you to expand your API's capabilities while maintaining backward compatibility. By following the principles and strategies outlined in this article, you can confidently add new fields, types, and arguments without causing disruptions to your clients.