前端开发人员希望构建出色的体验，然而，他们需要来自后端的数据并对后端执行操作。他们的问题的答案是API。谁构建了这些API？它们是快速构建还是前端开发人员等待？谁运行和管理API？毕竟，后端的行为方式并不统一——它们说不同的语言，发出不同形状的数据，有不同的身份验证要求等等。因此，运行和管理前端API并非易事。想要学习前端技术，可以参加Web前端培训，有更加全面系统的课程来学习，帮助你更好的理解与运用前端开发知识和技能。
以下是你通过作为前端和后端之间的齿轮箱的API思考时的一些注意事项。
1.API的形状很重要
是否有一种API语言比RESTAPI的“你从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，你需要一个工具来帮助你构建和运行设计良好且性能良好的GraphQLAPI。然后，你可能希望在开发门户、分析和一些使用API管理的前端密钥管理中分层。
结论
好的GraphQL端点必须平衡很多东西。我相信GraphQL真的很强大，对于前端和后端开发人员来说都是一个不错的选择，但是GraphQL是新的，构建GraphQLAPI的开发人员必须认识到最佳实践和权衡，他们必须做出有意识的决定来做正确的事。最终，推动平衡的系统和工具将成为构建开发人员和使用GraphQLAPI的开发人员的最佳工具。如果你想往前端的方向走，还有更多的东西要学，可以报个Web前端培训班，有系统全面的课程和明确清晰的学习路线，让学习更轻松更有效。