以下是你通过作为前端和后端之间的齿轮箱的 API 思考时的一些注意事项。

1. API 的形状很重要

是否有一种 API 语言比 REST API 的“你从 JSON 响应中得到什么”更灵活，并且比“随心所欲”更适合作为 SQL 构造?原来有GraphQL。对于前端开发人员来说，这太棒了。对于构建 API 的人来说，这同样很棒。为什么?因为它允许连接点、自动文档和“需要时抽象;不需要时详细。”我强烈建议将 GraphQL 实现为这些变速箱 API 的形状。

2. 抽象后端很重要

从根本上说，前端应用程序并不关心数据来自哪里，他们只想要数据。这意味着无论数据来自 REST 端点、SQL 数据库、NoSQL 数据库、GraphQL 后端，甚至是 WSDL/XML 后端，前端都不应该关心。如果有两个不同的后端将数据输入一个通用类型，那就这样吧，前端不应该关心。

3. 性能和可靠性问题

有两种方法可以做 API。要么每个 API 都承担着处理性能(“让我引入缓存”)或错误(“这个后端有时会发出错误数据，让我编写逻辑来绕过它”)的负担，或者每个 API 都声明它的内容这样做，系统就会观察并做正确的事情。第二种模式更可取——想想 SQL，你不编码错误条件或性能。相反，数据库试图并且几乎总是做正确的事情。

4. 如何构建 API 很重要

前端团队的需求随着客户和市场的需求而不断发展。并且同时存在多个前端需求。跟上这一切并不容易。当然，你可以启动一个程序，对其进行编码，并随着需求的发展来管理其生命周期。该程序承担了性能、可靠性等方面的负担。或者，你可以使用声明性构造构建 API — 使用来自后端 Y 的调用实现类型 X。类型 Z 使用此字段连接到类型 X。声明式构造允许快速构建 API。声明式结构还有另外两个真正有用的目的：(i)它们使业务逻辑远离前端 API 和(ii)它们导致更好的部署和运行时特性，因为它更容易推理和采取行动，一个使用声明性构造构建的 API。

5. 部署和运行时特性很重要

启动并运行 API 很重要，但是到达那个点的路比前面的路要短得多。后端永远不稳定，密钥被撤销，不良数据被发出，程序需要扩展，需要监控性能，谁在这样做? API 团队越来越多地采用 API 即服务作为这些日常运营问题的解决方案。

6. API 安全问题

API 为前端团队提供了很大的灵活性和对数据的访问，他们允许他们建立很棒的体验，但是现在，需要做些什么来确保不发生坏事呢?你有后端密钥要管理，你可以管理前端访问控制，如果你决定使用 GraphQL，你会更加头疼“我的突变端点不应该可访问”或“浏览器是否更改了查询参数并且现在正在询问不应该访问的数据?” API 管理可以解决一些问题，但一般来说，GraphQL 和后端密钥相关的问题无法通过围绕你的 API 进行分层 API 管理来解决。

7. 这是API管理吗?

API 管理不应与 API 混淆。虽然许多 API 管理产品允许你在其工具中构建 API，但你越来越希望在适合该 API 的工具中构建 API。例如，如果你的 API 是 GraphQL，你需要一个工具来帮助你构建和运行设计良好且性能良好的 GraphQL API。然后，你可能希望在开发门户、分析和一些使用 API 管理的前端密钥管理中分层。

结论

好的 GraphQL 端点必须平衡很多东西。我相信 GraphQL 真的很强大，对于前端和后端开发人员来说都是一个不错的选择，但是 GraphQL 是新的，构建 GraphQL API 的开发人员必须认识到最佳实践和权衡，他们必须做出有意识的决定来做正确的事。最终，推动平衡的系统和工具将成为构建开发人员和使用 GraphQL API 的开发人员的最佳工具。