你写的才是最好的 (GraphQL) API

听着，我不是 GraphQL 专家，但我确实喜欢使用它。它向我（作为一名前端开发人员）公开数据的方式非常酷。它就像一个可用数据的菜单，我可以要求任何我想要的东西。这比 REST 提升了巨大，并极大地赋予了我作为一名前端开发人员的力量，我渴望用我认为最适合 UI 的数据来设计组件，而无需为数据进行大量调用，或者请求后端开发人员帮助我为我的新需求创建一个新的定制 API。

但是……是谁构建了这个数据菜单呢？肯定有人。

如果这个人是你公司的人或团队，因为你已经为自己的需求构建了自己的 GraphQL API，那就太棒了。现在，你可以控制里面放什么（以及何时何地）。

但有时 GraphQL API 会直接提供给你。也许这就是你的 CMS 提供数据的方式。仍然很酷，很有用，但这种控制权掌握在 CMS 的手中。你仍然有一个选项菜单，但菜单就是这样。正如比喻所言，没有替代品。如果菜单上没有你想要的东西，你就不能回到厨房，给那个鲁宾三明治加点酸菜，或者让薯条配上炸蘑菇。

这在与 Simen Skogsrud 和 Knut Melvær 在 ShopTalk 的一集节目中进行的讨论中出现。他们的产品 Sanity 就像 JSON 数据的云存储，如果你需要的话，它也是一个 CMS。你可能会认为像这样的现代产品会毫不犹豫地使用 GraphQL API，事实上，他们确实有一个测试版。

但他们并没有将 GraphQL 作为查询和修改数据的首要方式，而是使用了他们自己的特殊语言：GROQ。乍一看，我的感觉是：天啊，这里有一个自寻死路的方法。发明一些人们必须学习的特殊语言，而这种语言是你的产品独有的，而不是新兴的行业标准。

但 Simen 和 Knut 提出了一个关于 GraphQL 在第三方为你提供 API 的情况下的一些局限性的观点：你只能得到你得到的。假设一个 GraphQL API 提供了一种检索作者的方法。一个通用的 API 可能会这样设计

{
  allAuthors {
    author {
      name
      username
      avatar
    }
  }
}

但实际上我想要的只是我们网站上有多少位作者。也许我希望我可以这样做

{
  allAuthors {
    count
  }
}

但这不在我被提供的 API 中。好吧，太糟糕了。我想我只能请求所有作者，然后自己统计。我可能无法控制 API。

这意味着，像提供 GraphQL 端点的 CMS 一样，需要做出选择。他们要么非常严格，你只能得到你得到的。要么，他们不仅提供 GraphQL API，还提供一种方法来控制和扩展该 API 的内容。

就 Sanity 而言，他们没有提供后者，而是提供了 GROQ，这是一种查询语言，它功能强大，可以让你从（JSON）数据中获得任何你想要的东西。而且，他们没有把它变成仅限 Sanity 的专有东西，而是开源了它。

使用 GROQ，我不需要任何权限或对 API 的修改来询问有多少作者。我可能会做一些像……

{ "totalAuthors": count(*[_type == "author"]) }

（实际上，我不知道上面的代码是否准确，当然，它取决于它所查询的 JSON，但这只是概念性的。）

通过提供一种能够从数据存储中选择任何可能数据的查询语言，它具有很大的优势

你可以查询任何东西
你不需要中间配置层

但它也有一些代价

语法复杂性
没有中间层意味着减少了连接多个 API、根据权限仅公开某些数据的可能性，等等。

评论