通用API并不能很好地去服务于前端
发布时间：2022-02-09 09:53:17 所属栏目：大数据 来源：互联网
导读：为什么不行？ 在设计通用 API 时，你会遇到一系列闹心的问题：如何预测和支持所有可能的工作流程？如何避免某些蹩脚的工作流程中的 N+1 问题？如何测试每个可能出现的请求的功能、性能和安全性？如何在不破坏现有工作流程的情况下修改某个 API？何根据内部和
|
为什么不行？ 在设计通用 API 时，你会遇到一系列闹心的问题：如何预测和支持所有可能的工作流程？如何避免某些蹩脚的工作流程中的 N+1 问题？如何测试每个可能出现的请求的功能、性能和安全性？如何在不破坏现有工作流程的情况下修改某个 API？何根据内部和社区的需求，划分修改 API 的优先级？如何完善文档，以方便各方顺利完成工作？ 从前端的角度来看，还有更多问题需要考虑：如何收集渲染页面所需的所有数据？如何优化发往多个端点的多个请求？如何避免以预期之外的方式使用 API 数据字段？如何权衡新功能与构建新 API 的成本？如果只是为了前端而构建后端，你需要考虑这么多问题吗？你需要考虑每一种可能的工作流程，避免 N+1 请求问题，测试每个请求配置？还是应该拒绝某些功能，因为你非常清楚每个页面需要呈现什么？看到这里，你可能明白我想说什么了。 建议:我建议不要将前端视为某个通用 API 的客户端，应将其视为应用的一半。 假设你可以把整个页面所需的 JSON 全部发送给前端。那么只需要创建一个端点/page/a，然后渲染/page/a的整个JSON就可以了。而且，每个页面都应该采用相同的做法。不要强迫前端开发人员发送一堆单独的请求来渲染复杂的页面。不要人为地制造的限制。 这个 JSON 需要负责渲染整个页面。不要渲染抽象模型和集合，而是应该渲染具体的方框、小节、段落、列表等。渲染可视化页面结构。这与服务器驱动 UI 类似，但不完全相同。我们可以称之为服务器通知 UI。 哪种方法更好？看到上面那些繁杂的考虑事项了吗？设计前端专用的 API 就不会为这些问题闹心了。 你可以自由决定：我想要一个页面A。然后只需在后端和前端实现页面A。非常简单。我们无需再考虑：必须引入哪些 API 工作流程，才能成功地渲染这个页面？页面 A 的实现非常简单，只需要实现页面本身的功能。你可以完整地测试页面A，检查 Bug、安全和性能问题。你甚至可以通过一个大型 SQL 查询语句，获取页面 A 所需的所有数据。你可以将页面 A 的整个 JSON 放入缓存。 前端非常清楚页面 A 中每个字段的用途。这些字段没有歧义，它们准确地代表了前端的需求。当需要修改页面 A 时，你只需径直打开页面 A，完成修改就行了，无需花大把时间开会讨论如何修改后端 API 才能实现前端的变更。这个 API 只服务于页面 A，不需要精心设计服务多个请求。只有这样，我们才能摆脱自我强加的限制。 此外，业务逻辑可以全部交由后端负责，无需在前端和后端之间的分工上浪费精力。前端可以专心呈现页面，而后端则可以专心实现前端所需的内容。目标明确，不是吗？ 如何实践？ 我曾在多个生产项目中尝试过这种做法。其中有一个是个人的项目，还有一个是在公司现有项目的基础之上进行的重构。我们整个团队都参与了那个项目，而且效果很好。我们遇到的唯一问题就是，前端的工作越来越无聊，因为几乎所有的业务逻辑都由后端负责。同时，后端团队也没有感觉到太大压力。而且大多数时候，我们谈论的都是业务相关的内容，而不是代码。 （编辑：宁德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
