以下是您在思考充当前端和后端之间变速箱的API时的一些注意事项。1.API的形式很重要有没有一种API语言比RESTAPI的“你从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为前端团队提供了很大的灵活性和对数据的访问权限，它们使他们能够构建出色的体验，但是现在，需要做些什么来确保不会发生坏事？你有后端的secretKeys来管理，你可以管理前端的访问控制，如果你决定使用GraphQL，你将会有更多的头痛“我的突变端点不应该被访问”或者“浏览器是否更改了查询参数和现在正在请求不应该访问的数据？”API管理可以解决一些问题，但一般来说，与GraphQL和后端密钥相关的问题无法通过围绕您的API进行分层API管理来解决。7.这是API管理吗？API管理不应与API混淆。虽然许多API管理产品允许您在其工具中构建API，但您越来越希望在适合该API的工具中构建API。例如，如果您的API是GraphQL，则您需要一个工具来帮助您构建并运行一个设计良好且性能良好的GraphQLAPI。然后，您可能希望使用API管理在开发门户、分析和一些前端密钥管理中分层。结论一个好的GraphQL端点必须平衡许多事情。我相信GraphQL确实很强大，对于前端和后端开发人员来说都是不错的选择，但是GraphQL是新的，构建GraphQLAPI的开发人员必须了解最佳实践和权衡，他们必须有意识地做出正确的决定事物。最终，推动平衡的系统和工具将成为开发人员构建和使用GraphQLAPI的最佳工具。
