前端开发注意事项-底层开发和前端开发

前端开发人员想要构建出色的体验前端开发注意事项，但是，他们需要来自后端的数据并在后端采取行动。 他们的问题的答案是 API。 谁构建了这些 API？ 他们是快速构建还是前端开发人员在等待？ 谁运行和管理 API？ 毕竟，后端的行为并不统一——它们使用不同的语言、以不同的形式发出数据、具有不同的身份验证要求等。因此，运行和管理前端 API 并非易事。

当您通过充当前端和后端之间的齿轮箱的 API 思考时，这里有一些注意事项。

1. API 的形状很重要

是否有比 REST API 的“你从 JSON 响应中得到什么”更灵活的 API 语言，以及比“随心所欲”更好的 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 的最佳工具。