我應該制作自己的graphql樣式api，但只能使用續集嗎？

Question

語境

嗨！ 我做了類似graphql的東西，但僅使用了Sequelize。 我的意思是，Sequelize查詢選項是JSON對象，因此，客戶端可以直接發送選項（使用正確的清理方法）。

我做了什么

出於好奇，我建立了它，並且效果很好。 現在我的疑問是：那有多糟？

這是使用此API的客戶端的示例

    const res = await http.post(APIs.FINDER, {
      model: 'User',
      options: {
        where: {
          id: someId
        },
        attributes: ['name', 'active']
      },
      include: [
          {
            as: 'zone',
            attributes: ['name']
          }
      ],
      order: [['createdAt', 'DESC']]
    });

好吧？

消毒/約束

關於消毒，我必須：

• 檢查包含項是否具有已知限制，例如：嵌套的包含項不超過10個
• 檢查參數是否不是SQL字符串或其他技巧（Sequelize對此有所注意）
• 不允許Sequelize函數，僅允許簡單查詢

問題

考慮到這一點，我認為這可以用於生產中。

• 我是否錯過了一些可以在生產使用中拒絕這個想法的東西？ （安全/使用/等）
• graphql是否具有一些使我更喜歡此自定義解決方案的特定功能？
• 您會在生產環境中使用它嗎？ 我無法想象為什么不

Answer 1

我對以下問題的看法：

1. 我不推薦這種風格的API。 它將使您的后端實現向公眾公開，這使您難以處理所有安全條件，更不用說業務邏輯和授權了。 另外，由於行為與sequ​​elize程序包緊密相關，因此很難提高性能。

2. 您可以考慮這篇文章： GraphQL突變設計：貧血突變 。 一個好的GraphQL API應該由領域和需求驅動，而不是由數據驅動。

3. 沒有！ 我在處理這種api樣式時遇到了困難。

---

實際上，這不是一個好主意。 如果您正在組織一個單人的全棧項目，乍一看它可能看起來很快，但是開發成本會飛漲，直到您不能繼續前進為止。 如果您是一個小組，則可能會注意到客戶端與服務器端緊密相連，這對開發非常不利。

在客戶端，它只需要有限的一組api，而不需要無限的api。

在服務器端，您什么也做不了，只能將數據移交給序列化，這很難提高性能，添加邏輯層以及將其他數據庫系統（例如彈性搜索）引入您的代碼庫。

在設計API時，可以考慮稱為DDD的域驅動設計 。 與使用GET { type: 'User", where: ..., include: ..., order: ..., limit: 10 }相比，首選使用GET Friends?limit=10 api GET { type: 'User", where: ..., include: ..., order: ..., limit: 10 }

順便說一句，GraphQL不僅是一種查詢語言，本質上還是一個薄API層（ ref ）。 因此，請勿將其用作JSON數據庫，而應將其視為關注業務需求的API。

例如，這是一個用戶模型：

{
  "User": {
    "id": 1,
    "name": "Mary",
    "age": 20,
    "friendIds": [2, 3, 4] 
  }
}

但是在GraphQL中，根據您的需要，它可能變為：

type User {
  id: ID
  name: String
  friends: [User]
  friendCount: Int
  friendsOverAge18: [User]
}

您可以閱讀有關如何設計GraphQL API的精彩文章： Shopify / graphql-design-tutorial