前端开发人员希望构建出色的体验，然而，他们需要来自后端的数据并对后端执行操作。他们的问题的答案是 API。谁构建了这些 API? 它们是快速构建还是前端开发人员等待？ 谁运行和管理 API? 毕竟，后端的行为方式并不统一——它们说不同的语言，发出不同形状的数据，有不同的身份验证要求等等。因此，运行和管理前端 API 并非易事。想要学习前端技术，可以参加Web前端培训，有更加全面系统的课程来学习，帮助你更好的理解与运用前端开发知识和技能。

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

　　1. API 的形状很重要

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

　　2. 抽象后端很重要

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

　　3. 性能和可靠性问题

　　有两种方法可以做 API。要么每个 API 都承担着处理性能(“让我引入缓存”)或错误(“这个后端有时会发出错误数据，让我编写逻辑来绕过它”)的负担，或者每个 API 都声明它的内容这样做，系统就会观察并做正确的事情。第二种模式更可取——想想 SQL，你不编码错误条件或性能。相反，数据库试图并且几乎总是做正确的事情。在Web前端培训中，有经验丰富的专业老师面授指导教学，通过理论结合实战的方式教授前端知识，让你快速学会前端技术。

　　4. 如何构建 API 很重要

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

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

　　启动并运行 API 很重要，但是到达那个点的路比前面的路要短得多。后端永远不稳定，密钥被撤销，不良数据被发出，程序需要扩展，需要监控性能，谁在这样做? API 团队越来越多地采用 API 即服务作为这些日常运营问题的解决方案。参加Web前端培训是入门学习的最佳选择，在短时间内尽快掌握JavaScript的相关知识，有助于你更好地进行开发工作。

　　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 的开发人员的最佳工具。如果你想往前端的方向走，还有更多的东西要学，可以报个Web前端培训班，有系统全面的课程和明确清晰的学习路线，让学习更轻松更有效。