如何处理前端后端的复杂性浏览器向Web应用程序端点发送请求，该端点从数据库中获取数据并返回响应。移动客户端的兴起以及与其他应用程序的集成打破了这种简单性。本文讨论了处理复杂性的解决方案。增加系统架构的复杂性首先，我们需要对上面描述的简单架构进行建模。移动客户端改变了这种方式。移动客户端的显示区域较小，例如平板电脑，手机。一种可能的解决方案是返回所有数据并让每个客户端过滤掉不需要的数据。不幸的是，移动客户端也遭受带宽不足的困扰，而且并非所有手机都支持5G。即便如此，如果它在偏僻的地方并且连接点只提供H+，那也没用。因此，它不能被过度提取。每个客户端都需要不同的数据子集。使用单体，可以为每个客户端提供多个端点。可以在前端设计一个特定层的Web应用程序，该层检测发出请求的客户端并过滤掉响应中不相关的数据，Web应用程序中的过度获取不是问题。微服务如今风靡一时，每个人和他们的邻居都希望实现微服务架构。微服务的背后是“两个披萨团队”的思想。每个团队都是自治的，负责一个微服务或一个前端应用程序。为了避免开发工作之间的耦合，每个微服务团队都会发布其API合约并非常谨慎地处理变更。每个微服务都需要为每种类型的客户端提供严格必要的数据，以避免上述过度获取问题。对于少量的微服务，让每个微服务根据客户端过滤数据很麻烦，大量的微服务显然是不可能的，所以微服务数量和不同客户端数量之间的笛卡尔因子使得每个微服务的成本互联网上专用数据端点的数量呈指数级增长。解决方案：前端BFF后端背后的想法是将逻辑从每个微服务移动到专用的可部署端点。后者负责：从每个所需的微服务中获取数据，提取相关部分，聚合它们，最后返回同一个团队，以与特定客户端相关的格式开发客户端及其相关的BFF。BFF提供与微服务相同的权衡：通过增加系统复杂性来提高开发速度。独立部署单元与API网关有关BFF的文献暗示了专用部署单元，如上图所示。一些文章，比如这篇文章，反对使用API网关的BFF。但概念图不一定与部署图一一对应。与许多领域一样，人们应该更多地关注组织方面而不是技术方面。在这种情况下，最关键的一点是负责前端的团队同时负责BFF。无论是单独的部署单元还是API网关配置的一部分，都是一个实现细节。例如，使用ApacheAPISIX，每个团队都可以将他们的BFF代码独立部署为一个单独的插件。性能考虑对于单体，情况如下：从客户端到单体的请求需要特定的时间T。它通过Internet传输，T可能很长。内部对数据库的不同调用与T相比可以忽略不计。一旦迁移到微服务，客户端需要依次调用每个微服务。因此，对于顺序调用，时间变为∑(T1,T2,Ti,Tn)。由于这是不可接受的，因此客户端通常使用并行调用。时间变为最大值（T1、T2、Ti、Tn）。请注意，即使这样，客户端也需要执行n个请求。在BFF的情况下，无论实现什么，我们都会在T时间内返回一个请求。与单体相比，从BFF到微服务的请求t1、t2、ti、tn多了一些，但它们可能位于一起。所以整体时间会比单体长一些，但是由于每个t都比T短很多，所以不会对用户体验造成太大影响。结论您可能不应该实施微服务。如果这样做，微服务不应该返回整个数据，而是让客户端负责清洗这些数据。因此，微服务需要根据客户端准确返回所需的数据。它在微服务和客户端之间引入了强耦合。你想删除这个耦合。为实现这一点，前端后端方法将每个服务的清理逻辑提取到一个专用组件中，该组件还负责聚合数据。每个客户团队还负责其专用的BFF：当客户更改其数据要求时，该团队可以部署适应新要求的新版本BFF。BFF是一个概念性的解决方案。不需要将提取/清理/聚合逻辑放在特定位置。它可以是一个专用的部署单元，也可以是API网关中的一个插件。在以后的文章中，将展示本文中描述的不同步骤。原文链接：https://dzone.com/articles/discussing-backend-for-front-end译者简介康少京，社区编辑，目前从事通信行业，从事底层驱动开发岗位，以及学过数据结构和Python。对操作系统、数据库等相关领域感兴趣。
