- 综合排序
- 最热优先
- 最新优先
- 来自专栏网络日志
graphql+koa2 前端bff层
使用graphql的优势： 前端把握查询的主动权，可定义你需要查询的字段过滤冗余，另外减少两端的沟通 接手bff层前端可作为空间更大，包括做一些鉴权 请求合并更加便利（以前初始化多个请求需要一起返回都是使用 另外后端同学对于bff层其实不怎么感冒，因为数据聚合对他们来说没什么含量，完全是对前端同学服务。所以我们完全可以引入查询来接手后端同学的bff层。 后端同学直接集成 (java接口(restful或者graphql)-->前端) 前端增加中间服务层（java接口-->前端中间服务层nodejs(graphql)-->前端） 对于第一种方式，后端同学可能更改会更大 前端中间服务层的配置 中间服务层使用koa2搭建，当然你也可以使用express等等其他。 graphql的查询中另外一个比较好的地方在于指令，指令的加入会让bff层更加有做为（放在下一次讲）
55010编辑于 2024-05-30 - 来自专栏Web行业观察
前端构建BFF层创建业务中间后端逻辑架构
BFF层的作用 BFF层的主要作用包括： 数据聚合：将来自多个后端服务的数据聚合成前端需要的格式。 协议转换：将后端服务的RESTful API或GraphQL API转换为前端更易用的接口。 选择BFF框架 在搭建BFF层时，选择一个合适的框架非常重要。以下是一些常用的BFF框架： Node.js + Express/Koa：适合小型项目或团队，易于上手。 我们以Node.js + Express为例，详细介绍如何搭建BFF层。 安装Node.js和npm 在开始之前，确保你的计算机上已经安装了Node.js和npm。 安装完成后，可以通过以下命令检查Node.js和npm的版本： node -v npm -v 创建项目目录 首先，创建一个新的项目目录，并进入该目录： mkdir bff-project cd bff-project 集成认证和授权 为了确保前端请求的安全性，我们可以在BFF层集成认证和授权逻辑。
78910编辑于 2024-12-06 - 来自专栏黯羽轻扬
Backend For Frontend (BFF)
复用问题 拆开之后，多个BFF之间容易产生冗余代码，尤其是一些通用的后端逻辑（如授权、认证、限流等等） 为了消除BFF间的代码冗余，一般采用两种做法： 要么多BFF合一 要么在BFF之上加一层Edge 具体实践中，BFF通常不是图示的样子，主要变化在于： 按业务线拆分BFF 加一层网关，负责实现路由、认证、监控、限流熔断、安全等功能 按业务线拆分的BFF更像是建立在下游基础服务之上的业务型微服务，只是这些微服务由对应业务的前端团队负责开发维护 广义的，可以理解为更细粒度的BFF，即每块业务对应一个BFF（不再按用户体验差异去分） 网关层负责实现通用的边界服务，如认证、限流等，让BFF更专注于业务相关的部分： 前端体验 ------------ -- ----- BFF BFF ----- ----- ^ ^ ^ ^ / \ / \ -------------------- 下游服务 P.S.另外，还有不引入BFF，而只添一层转发服务来解决数据的聚合 从分工的角度看： BFF模式不仅仅是一种技术架构，从社会分工角度讲，BFF更是一种多元价值导向的分层架构，每一层都有不错的空间去施展。
2.8K40发布于 2019-06-12 - 来自专栏黑客下午茶
一种不错的 BFF Microservice GraphQLREST API 层的开发方式
还添加了基于响应性扩展的示例，以演示如何将其用于构建微服务 API 边缘服务（edge-service）、前端的后端（BFF）或将其用作构建任何类型微服务的基础。 swapi.co/api/people/1/", "http://swapi.co/api/people/2/", "http://swapi.co/api/people/4/ ], films: [ "http://swapi.co/api/films/5/", "http://swapi.co/api/films/4/ JWT token 是属性 idToken 的值 { "idToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiYWRtaW4iLCJpYXQiOjE1MTQ4NjQ3ODMsImV4cCI6MTUxNDg2ODM4Mywic3ViIjoidGVzdEBnbWFpbC5jb20ifQ.hAEa6AL1Kxxxxxxx 版本 jestSonar": { "reportPath": "reports", "reportFile": "test-reporter.xml", "indent": 4,
3.5K10发布于 2021-05-27 - 来自专栏JavaEdge
BFF 架构简介
Sam Newman详细地说明了BFF。 客户端都不是直接访问服务器的公共接口，而是调用BFF层提供的接口，BFF层再调用基层的公共服务，不同的客户端拥有不同的BFF层，它们定制客户端需要的API。 而使用BFF在很大程度能避免这样的问题。 使用BFF的另一个优点就是当由于某一客户端需要调用调用多个不同的服务端接口来实现某一功能时，可以直接在对应的BFF层编写相应的API，而不会影响到基层的公共服务，且客户端不用直接向多个后台发起调用，可以优化性能 当然，凡事有利有弊，BFF带来便利好处的同时也会引起一些问题，如代码重复，加大开发工作量等。所以在使用时需要结合现实情况仔细斟酌，符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景如下。 ?
1.6K30发布于 2021-02-23 - 来自专栏随心分享
BFF与Nestjs实战
适用场景 BFF虽然比较流行，但不能为了流行而使用，要满足一定的场景并且基建很完善的情况下才使用，否则只会增加项目维护成本和风险，收益却非常小，我认为的适用场景如下： 后端有稳定的领域服务，需要聚合层 需求变化频繁，接口经常需要变动：后端有一套稳定的领域服务为多个项目服务，变动的话成本较高，而bff层针对单一的项目，在bff层变动可以实现最小成本的改动。 总结 经过上文我们可以对BFF层的概念有一个基本的了解，并且按照步骤可以自己搭建一个Nestjs小应用，但和企业级应用差距还很大。 接BFF层需要有完善的基建和合适的业务场景，不要盲目接入 Nestjs基于Express实现，参考了springboot的设计思想，入门很简单，精通需要理解其原理，尤其是依赖注入的设计思想 参考文献 我理解的 BFF NestJs官方文档
3.5K10编辑于 2022-11-19 - 来自专栏ThoughtWorks
探索原味BFF模式
BFF — Backend For Frontends，经典分布式架构设计模式之一。我在学习和工作经验累积中，逐渐加深了对 BFF 的理解。 寻找历史的线头 在毫无头绪的情况下，我们可以首先从Thoughtworks技术雷达中 BFF 的条目入手，去找到一些历史的蛛丝马迹。BFF 条目的发布时间是在 2015 年 11 月10 日。 终于，我们可以说 BFF 模式是在解决 SoundCloud的分布式系统问题中首次出现。下面，让我们一起回到BFF第一次发挥威力的现场吧。 BFF 新的形态出现了，具体如下图所示： 随着时间推移，SoundCloud 的 BFF 也在增加。他们已经在生产环境同时维护着 5 个 BFF 了。为了进一步提高生产力，减少不必要的重复。 SoundCloud 的 BFF 依然随着时间在横向增长，不同的是这种横向增长不会再引起任何问题了。最终，BFF 模式的架构演变成与我们现在使用的几乎一致了。
75020编辑于 2022-09-14 - 来自专栏Tencent Serverless 官方专栏
Yunong Xiao : Serverless Is Your BFF
然而语言只是服务端开发最表层也是最易突破的一层，可靠性、速度性能、安全性、架构可扩展性、甚至运维，都是前端向全栈发展需要考虑的关键因素。 10月20日， JSConf大会上，腾讯云中间件总经理 Yunong Xiao 将发表《Serverless Is Your BFF》主题演讲，从前端发展演进、前端到全栈的路径和问题以及如何利用Severless
98040发布于 2019-10-21 - 来自专栏负载均衡
Nginx4层与7层配置详解
/nginx -s stop 停止4../nginx-s quit 安全退出. 192.168.1.103:8080; } server { listen 80; location / { proxy_pass http://backend; } }}3.7 整体测试拓扑3.7.1 Nginx4层负载测试 3.7.2 Nginx7层http负载测试1、根据拓扑图，将节点中的IP配置好。2、配置Nginx： 配置服务器和监听端口等。 3.7.3 Nginx7层https负载测试1、根据拓扑图，将节点中的IP配置好。2、配置Nginx： 配置服务器和监听端口等。 4、准备测试环境：准备至少四个服务器，一个作为客户端，一个作为代理服务器，两个作为目标服务器。确保服务器之间可以相互访问，并且nginx服务器能够访问到目标服务器。
57000编辑于 2024-07-15 - 来自专栏Ywrby
4-网络层（上）
网络层基础 在参考模型中网络层位于传输层之下，链路层之上。 网络层的功能主要是将源端产生的数据包/分组，送达至目的机 完成这项工作需要： 封装源数据 识别目的机 找到一条好的路径（路由） 可能遭遇的问题： 地址不够用 丢包 拥塞 网络层主要内容 被路由协议：IP 在网络层上，可将整个互联网看作是一组互联的子网络的自治系统 将整个互联网联合起来的正是网络层协议：IP IP的目的是提供一种尽力的传送方式，将数据从源传到目的 IP寻址：根据目的IP地址，找到目的网络的过程 17表示UDP），指定上层传输层协议。 ，也就是IPv4或IPv6是孤岛时的通信 翻译转换技术 从IPv4转换到IPv6，或反过来，不仅发生在网络层，还有传输层和应用层。
1.3K30编辑于 2022-10-27 - 来自专栏初见Linux
4.网络层-IP
网络层 1.作用 网络层控制子网的通信，通过路由选择算法为分组通过通信子网选择最适当的传输路径，实现流量控制、拥塞控制与网络互联的功能。 IP是TCP/IP体系中的网络层协议(相当于OSI模型的网络层)，同时是整个TCP/IP协议族的核心，也是构成互联网的基础。 （1）版本号：4位. 占4位。 就是IP协议的版本，通信双方的IP协议必须要达到一致，IPv4的版本就是0100。 （2）首部长度(IHL)：4位 （5-4-32；20-15-60）占4位，所以首部长度的最大值为1111，15，又因为首部长度代表的单位长度为32个字（也就是4个字节），所以首部长度的最小值就是0101 ，IPv4的首段长度一定是4字节的整数倍，要是不是怎么办呢？
1.3K20发布于 2020-08-05 - 来自专栏初见Linux
4.网络层-ICMP
它是TCP/IP协议簇的一个子协议，一般认为属于IP层协议，用于在IP主机、路由器之间传递控制消息。属于网络层协议。 控制消息：是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。 （前4个位都是一样的） （2）代码：8位 （3）校验和：16位 以上是三个长度固定的字段，共4字节。 （4）参数： 不同的ICMP类型有不同的参数。 （这4个字节取决于ICMP报文的类型） （5）信息（可变长）： 长度也取决于类型。 3.ICMP协议分类 可分为 差错报告报文 和 ICMP询问报文。 4.不同的ICMP类型代表不同意义: （重要考点） 重定向、回声、不可达常考。 （1）类型4（源抑制报文） 堵塞时会发类型4，源抑制报文告诉它降速。 时间戳报文和Traceroute命令有关 （4）类型17/18（地址掩码报文） 类型17：请求。类型18：应答。 总结：ICMP 会和 PING 、Traceroute命令结合。
75940发布于 2020-08-05 - 来自专栏AIoT技术交流、分享
4层板到12层板叠层经典设计方案
目录 1、4层板优选叠层方案 2、6层板优选叠层方案 3、8层板优选叠层方案 4、10层板优选叠层方案 5、12层板优选叠层方案 6、总结 ---- 电路板的叠层设计是对PCB的整个系统设计的基础，叠层设计若有缺陷 1、4层板优选叠层方案 4层板优选叠层方案主要有三类： 方案一：为常见四层PCB的主选层设置方案。 方案二：适用于主要元器件在BOTTOM布局或关键信号底层布线的情况；一般情况限制使用。 4、10层板优选叠层方案 10层板优选叠层方案主要有五类： 对于单一电源层的情况，首先考虑方案一。层叠设置时，加大S1～S2、S3～S4的间距控制串扰。 对于需要两电源层的情况，首先考虑方案二。 层叠设置时，加大S1～S2、S3～S4的间距控制串扰。 5、12层板优选叠层方案 12层板优选叠层方案主要有五类： 方案二和方案四具有良好的EMC性能。 方案一和方案三具有较好的性价比。 ?
2.1K20发布于 2021-01-20 - 来自专栏SpringBoot 核心技术
初识BFF架构设计
最近在公司的微服务架构中遇到了一些多终端访问接口的问题，不同的终端拥有不同的接口服务，有不同的操作数据的能力，针对这种业务场景做出了调研，我们是否可以在不同的访问层进行业务逻辑处理，获取不同的数据内容呢 多端共用一个BFF ? 每个端提供一个BFF ? 如果我们为每一个端点都提供一个BFF，每个端点的BFF处理自身的业务逻辑，需要数据时从基础服务内获取，然后在接口返回之前进行组装数据用于实例化返回对象。 这样基础服务如果有新功能添加，BFF几乎不会受到影响，而我们如果后期把App端点进行拆分成Android、IOS时我们只需要将app-bff进行拆分为android-bff、ios-bff，基础服务同样也不会受到影响 也同样带来了一些问题，如下所示： 响应时间延迟（服务如果是内网之间访问，延迟时间较低） 编写起来较为浪费时间（因为在基础服务上添加的一层转发，所以会多写一部分代码） 业务异常处理（统一格式化业务异常的返回内容
2.3K50发布于 2019-10-09 - 来自专栏用户1392128的专栏
7层负载均衡与4层负载均衡区别
先说结论： 4 层负载均衡本质是转发，而 7 层负载本质是内容交换和代理 一、OSI 7层模型与TCP/IP 4层模型 OSI: open system interconnection 开放式系统互联参考模型 OSI 7层模型 TCP/IP 4层模型 应用层 应用层 表示层 应用层 会话层 应用层 传输层 传输层 网络层 传输层 数据链路层 数据链路层 物理层 数据链路层 网络七层模型是一个标准，而非实现 二、7层负载均衡与4层负载均衡 在OSI 7层模型中，从下往上，应用层属于第七层，而传输层属于第四层， 所谓四层即运输层，就是基于 IP + 端口的负载均衡； 七层即应用层，就是基于 URL 等应用层信息的负载均衡 4 层负载均衡本质是转发，而 7 层负载本质是内容交换和代理 以常见的 TCP 为例： 4 层负载均衡转发 负载均衡设备在接收到第一个来自客户端的 SYN 请求时，即通过上述方式选择一个最佳的服务器 三、7层负载均衡与4层负载均衡的对比 7层负载均衡相较于4层负载均衡在更耗费性能的同时，也获得了更加智能的优点，由于在应用层进行识别，所以7层负载均衡可以基于不同的协议（如http、radius、dns
1.4K11编辑于 2024-01-08 - 来自专栏码农那些事！！！
聊聊微服务中的 BFF 架构
此时，整个供应链系统的架构如下图所示： 上图中的网关层主要负责路由、认证、监控、限流熔断等工作。 路由：所有的请求都需要通过网关层进行处理，网关层再根据 URI 将请求指向对应的后台服务，如果同一个服务存在多个服务器节点，网关层还将承担负载均衡的工作。 认证：对所有的请求进行集中认证鉴权。 为了解决这 2 个问题，最终我们决定抽象一个 API 层。 API 层 一般来说，客户端的接口需要满足聚合、分布式调用、装饰这三种需求。 从图中我们发现，所有请求经过网关后，全部交由一个共用的 API 层进行处理，而该 API 层没有自己的数据库，它的主要职责是调用其他后台服务。 通过这样的设计方案后，以上两个问题就得到了很多地解决。 我们就可以考虑使用 BFF 了。 BFF（Backend for Front） BFF 不是一个架构，而是一个设计模式，它的主要职责是为前端设计出优雅的后台服务，即一个 API。
2.4K20编辑于 2023-05-01 - 来自专栏前端那些趣事
你学BFF和Serverless了吗
❝ 前沿：前段时间在公司内部分享了关于bff和serverless的知识体会，从概念、特征、和应用场景再到简单的实践，今天借此机会跟大家分享，什么是BFF? 什么是serverless？ ❞ 1.BFF ❝ 在聊Serverless之前跟大家先谈谈BFF，BFF顾名思义就是Backend For Frontend,用中文解释就是服务于前端的后端，那么为什么会有BFF？ ❞ 前端同学和后端同学都各有各的道理，有没有一种解决方案可以化解这种尴尬的场景，于是就有了BFF 1.1 介绍 ❝ BFF层初衷是在后台服务与前端（客户端）之间添加一层，接下来我们来看看下面这张图 ❞
90131发布于 2020-10-15 - 来自专栏ThoughtWorks
微服务下使用GraphQL构建BFF | 洞见
加入了BFF 的前后端架构 ? 加入了BFF的前后端架构中，最大的区别就是前端(Mobile, Web) 不再直接访问后端微服务，而是通过 BFF 层进行访问。并且每种客户端都会有一个BFF服务。 从微服务的角度来看，有了 BFF 之后，微服务之间的相互调用更少了。这是因为一些UI的逻辑在 BFF 层进行了处理。 比如作为在 BFF 层使用 GraphQL, 这一层的 BFF 并不需要任何的数据库或者存储媒介。 复杂数据请求：REST 对于嵌套的复杂数据需要多次调用，GraphQL 一次调用, 减少网络开销； 4. 在我们项目对应的业务场景下，微服务后台有近 10 个微服务，客户端包括针对不同角色的4个 App 以及一个 Web 端。对于每种类型的 App，都有一个 BFF 与之对应。
2.4K60发布于 2018-04-17 - 来自专栏架构精进之路
关于 BFF 架构设计的胖瘦之争
要不要使用 BFF 来编排后端服务？ BFF 是不是编排层？ BFF 能不能宏观上对应 DDD 的应用层？ ...... ，统一由 BFF 处理 不同类型的客户端一套 BFF 非常接近 DDD 四层架构中的应用层，处理面向场景的业务 因为它的职责比较多，我们暂且称其为：胖 BFF。 4. 瘦 BFF 的好处是： 端到端交付，前端开发人员直接使用后端领域服务的 API 文档 开发效率高，避免多编写一层 BFF 减少一次集成 对应的，瘦 BFF 的弊端可想而知： 没有编排层，服务之间相互依赖 项目周期和迭代速度 对于短期项目或需要快速迭代的项目，瘦 BFF 可以更快地实现并投入使用。而胖 BFF 的开发周期可能较长，但在长期运行中可以提供更好的性能和可维护性。 4.
41120编辑于 2024-12-06 - 来自专栏程序员成长指北
如何在中后台领域玩转BFF架构
比如一个商家详情页即需要仓储数据，也需要资产数据，此时我们在 BFF 层将仓储和资产数据请求回来组装吐给前端。 字段转换：字段过滤、数据格式化等工作。 比如资产域的商户名字段叫 businessName，而仓储域的商户名字段叫 shopName，此时可以在BFF层统一掉，这样前端就不需要做判断了。 BFF 核心架构 核心架构 以上是 BFF 的核心架构图，前端即中后台应用，后端域即后端服务，右侧的工具支撑是公司的一些基础公共服务，中间的就是 BFF 核心实现，我们从上往下看： 业务：可以在这一层做业务编排 调用链路 核心架构讲完后，再看下整个 BFF 架构的调用链路： 调用链路从上往下，我们的中后台应用通过 HTTP 请求到 Nginx 服务器上，Nginx 转发到 BFF 层，BFF 层通过 RPC 基于 Serverless 的BFF改造 SFF 架构 上图是改造后的BFF架构，相比于一代的 BFF 架构，这里主要多了两块内容，一块是 FaaS 层，另外一块是开发者平台。
1.8K30发布于 2021-08-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号