- 综合排序
- 最热优先
- 最新优先
- 来自专栏网络日志
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)
不难想到3种拆分方式： 用户体验级（UI级）：每一种UI交互对应一个BFF，比如PC端1个，移动端3个（例如小屏手机、中屏手机和大屏手机三者UI交互差异很大的话，有必要拆成3个BFF） 端级：每种前端设备对应一个 复用问题 拆开之后，多个BFF之间容易产生冗余代码，尤其是一些通用的后端逻辑（如授权、认证、限流等等） 为了消除BFF间的代码冗余，一般采用两种做法： 要么多BFF合一 要么在BFF之上加一层Edge 广义的，可以理解为更细粒度的BFF，即每块业务对应一个BFF（不再按用户体验差异去分） 网关层负责实现通用的边界服务，如认证、限流等，让BFF更专注于业务相关的部分： 前端体验 ------------ 的探索方向主要有3个： 稳定性：保障BFF的可靠性，如通过日志、错误分析、监控、报警等手段 同构：让BFF与前端体验使用相同的技术栈，如基于Node的同构方案 一体化：一方面针对下游服务提供mock方案 从分工的角度看： BFF模式不仅仅是一种技术架构，从社会分工角度讲，BFF更是一种多元价值导向的分层架构，每一层都有不错的空间去施展。
2.8K40发布于 2019-06-12 - 来自专栏黑客下午茶
一种不错的 BFF Microservice GraphQLREST API 层的开发方式
还添加了基于响应性扩展的示例，以演示如何将其用于构建微服务 API 边缘服务（edge-service）、前端的后端（BFF）或将其用作构建任何类型微服务的基础。 /swapi.co/api/films/4/", "http://swapi.co/api/films/6/", "http://swapi.co/api/films/3/ /swapi.co/api/films/2/", "http://swapi.co/api/films/6/", "http://swapi.co/api/films/3/ 它将给出一个错误（注意：错误处理需要改进，但是这里我们只看这个概念） Step 3 - 在执行 “examples” 查询之前，使用 Bearer token 设置授权头。 的值 { "idToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiYWRtaW4iLCJpYXQiOjE1MTQ4NjQ3ODMsImV4cCI6MTUxNDg2ODM4Mywic3ViIjoidGVzdEBnbWFpbC5jb20ifQ.hAEa6AL1Kxxxxxxx
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 - 来自专栏python3
OSI第3层：网络层
第 3 层使用了四个基本过程： 1） 编址；（IP地址） 2） 封装；（源IP地址和目的IP地址） 3） 路由；（数据包选择路径并将其转发到目的主机） 4） 解封。 （网络层解封该数据包，然后将数据包中包含的第 4 层 PDU 向上传 送到传输层的相应服务。） 网络层协议： 1) 在传送用户数据的网络层执行的协议包括： 2) Internet 协议第四版 (IPv4) 3) Internet 协议第六版 (IPv6) 4) Novell 互联网分组交换协议 3) 介质无关性 - 其运作与传送数据的介质无关。 丢弃 路由器处理数据包的过程： 1） 路由器收到一个数据包后删除第2层封装； 2） 提取目的IP地址； 3） 检查路由表中是否有匹配条目；（无匹配则丢弃） 4） 在路由表中找到此网络； 5）
99410发布于 2020-01-14 - 来自专栏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 - 来自专栏Ywrby
3-传输层
传输层 传输层概述 传输层是整个TCP/IP协议栈核心之一，位于网络层之上，应用层之下。利用网络层的服务，为上层应用层提供服务。 Trivial file transfer protocol 79 Finger Looking information about a user 80 HTTP World Wide Web 110 POP-3 传输线路的带宽有限 过多的分组同时通过输出线路进行传输，逼近传输链路的带宽极限，导致排队时延陡增，整条线路产生拥塞 3. CongWin=1 MSS，进入SS阶段 TCP平均吞吐量 使用窗口window尺寸W和RTT来描述 忽略慢启动阶段，假设发送端总有数据传输 W：发生丢失事件时的窗口尺寸（单位：字节） 平均窗口尺寸：3/ 4W 平均吞吐量：1RTT时间内吞吐3/4W avg TCP thruput=\frac{\frac{3}{4}W}{RTT}bytes/sec=\frac{3}{4}*\frac{W}{RTT}bytes
1.7K20编辑于 2022-10-27 - 来自专栏python3
3层交换技术
我们知道不同的vlan之间要相互的通行必须要借用第三层，也就是网络层，可以路由器也可以是三层的交换机。 三层拓扑图 图1-6 创建Vlan并设置为服务端 Switch>en Switch#vlan database Switch(vlan)#vlan 2 name vlan2 VLAN 2 added: Name:vlan2 Switch(vlan)#vlan 3 name vlan3 VLAN 3 added: Name:vlan3 Switch(vlan)#vtp server Switch(vlan 192.168.2.1 255.255.255.0 Switch(config-if)#no shut Switch(config-if)#exit Switch(config)#int vlan 3 Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan 3 Switch(config-if)
45410发布于 2020-01-09 - 来自专栏SpringBoot 核心技术
初识BFF架构设计
最近在公司的微服务架构中遇到了一些多终端访问接口的问题，不同的终端拥有不同的接口服务，有不同的操作数据的能力，针对这种业务场景做出了调研，我们是否可以在不同的访问层进行业务逻辑处理，获取不同的数据内容呢 多端共用一个BFF ? 每个端提供一个BFF ? 如果我们为每一个端点都提供一个BFF，每个端点的BFF处理自身的业务逻辑，需要数据时从基础服务内获取，然后在接口返回之前进行组装数据用于实例化返回对象。 这样基础服务如果有新功能添加，BFF几乎不会受到影响，而我们如果后期把App端点进行拆分成Android、IOS时我们只需要将app-bff进行拆分为android-bff、ios-bff，基础服务同样也不会受到影响 也同样带来了一些问题，如下所示： 响应时间延迟（服务如果是内网之间访问，延迟时间较低） 编写起来较为浪费时间（因为在基础服务上添加的一层转发，所以会多写一部分代码） 业务异常处理（统一格式化业务异常的返回内容
2.3K50发布于 2019-10-09 - 来自专栏python3
Catalyst2层交换的3层通信
当核心交换机配置第二IP，汇聚交换机的通过trunk连接到核心交换机，并且配置的接口IP和第二IP一个网段，当汇聚交换机没有启用3层路由功能的时候，它们之间可以正常通信，但当汇聚交换机启用3层路由功能之后 按照要求配置了3560G和2960S，当然2层的2960只能配ip default-gateway，的确是可以完全通信，没有任何问题，看来交换机和路由器的机制真的不一样。 打开2960的ip arp，发现刚才和交换机通信的并不是和交换机的IP一个网段的地址，也竟然都赫然在列，真正体现了2层交换，通信不靠IP路由，直接IP地址对应的就是mac地址，不是一个网段的也是这样，所以 2层交换机可以在2层的状态下，以2层的mac地址来通信，而启用了ip routing之后，按照3层的路由规则，反而不行了。
47410发布于 2020-01-14 - 来自专栏码农那些事！！！
聊聊微服务中的 BFF 架构
路由：所有的请求都需要通过网关层进行处理，网关层再根据 URI 将请求指向对应的后台服务，如果同一个服务存在多个服务器节点，网关层还将承担负载均衡的工作。 认证：对所有的请求进行集中认证鉴权。 为了解决这 2 个问题，最终我们决定抽象一个 API 层。 API 层 一般来说，客户端的接口需要满足聚合、分布式调用、装饰这三种需求。 客户端适配问题 在这个供应链系统中，一系列的接口主要供各种客户端（比如 App、H5、PC 网页、小程序等）进行调用，此时的调用关系如下图所示： 不过，这种设计方案会存在 3 个问题： 不同客户端的页面细节的需求可能不一样 我们就可以考虑使用 BFF 了。 BFF（Backend for Front） BFF 不是一个架构，而是一个设计模式，它的主要职责是为前端设计出优雅的后台服务，即一个 API。 然而，针对重复代码的问题，不同部门在设计时会呈现 3 种不同的逻辑： 某些部门将这些重复的代码存放在一个 JAR 中，让几个 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 - 来自专栏PHPer 进击
网络协议 3 - 从物理层到 MAC 层
今天，我们来认识下 物理层 和 MAC 层。 日常生活中，身为 90 后的我们，如果不是通信相关专业出身的，应该从来没有接触过物理层和 MAC 层的设备。我们接触最多的，可能就是路由器了。 而路由器实际上是第三层-网络层的设备了。 那咱们怎么认识物理层呢？就不扯那些深奥的理论了，从宿舍联机打魔兽说起吧。 他应该会回答你，有三种方式： 网线连接 集线器连接 交换机 物理层 上面三种方式中，网线连接和集线器是完全在物理层工作，咱们就先见识下这两种方式。 网线水晶头的第 1、2 和第 3、6脚，分别起着发、收信号的作用，要想通过一根网线将两台电脑连接在一个局域网上，需要额外做的操作就是将网线其中一端的 1 号和 3 号线、2 号和 6 号线互换一下位置， 但是因为第二层主要解决媒体接入控制的问题，所以它常常被称为 MAC 地址。 解决第一个问题就牵扯到第二层的网络包格式。
1.3K10发布于 2019-04-11 - 来自专栏ThoughtWorks
微服务下使用GraphQL构建BFF | 洞见
从微服务的角度来看，有了 BFF 之后，微服务之间的相互调用更少了。这是因为一些UI的逻辑在 BFF 层进行了处理。 3. , city } } } } 3. 比如作为在 BFF 层使用 GraphQL, 这一层的 BFF 并不需要任何的数据库或者存储媒介。 在我们这个系统中 BFF 层并不做鉴权服务，所有的鉴权过程全部由各自的微服务模块负责。BFF 只提供中转的功能。BFF 是否需要集成鉴权认证，主要看各系统自己的设计，并不是一个标准的实践。 3.
2.4K60发布于 2018-04-17 - 来自专栏飞鸟的专栏
3、OSI模型-物理层
一、物理层-网络的基础 物理层是OSI的最底层。 物理层为数据传输提供可靠的坏境 1、物理层的功能 规定介质类型、链接类型、信号类型 介质类型： 有线介质：双绞线、光纤 无线介质：无线电、微波、激光、红外线 10Base2 (10M基带传输200米) 100MHz 用于语音传输和最高传输速率为1000Mbps的数据传输 主要用于100Base-T和10Base-T的网络 6类线：传输频率为200MHz 向下兼容3类
62950编辑于 2022-01-05 - 来自专栏bug收集
代码生成器3-控制层与模型层
写后台管理系统，涉及大量的增，删除，改，查；而且使用分层开发文件太多，就想到能不能把基本的代码，通过一个代码生成器来生成，从而节约开发时间; （使用语言nodejs） tpl 文件夹： 关于控制层与模型层的模板 resolve(data); }).catch(function(err){ reject(err); }); }); } // 3. update{{ funName }} } controller 文件夹 根据模板，生成 model 文件与 controller 文件 步骤如下： 获取用户提供的表名 根据表名，获取对应的列名 3. resolve(data); }).catch(function(err){ reject(err); }); }); } 3. `; return updateSql; } Nodejs生成的三层架构，就分享结束！！^_^
61110编辑于 2022-07-22 - 来自专栏架构精进之路
关于 BFF 架构设计的胖瘦之争
要不要使用 BFF 来编排后端服务？ BFF 是不是编排层？ BFF 能不能宏观上对应 DDD 的应用层？ ...... 概括而言：不同 BFF 的考量会决定微服务架构的两种形态。 3. ，统一由 BFF 处理 不同类型的客户端一套 BFF 非常接近 DDD 四层架构中的应用层，处理面向场景的业务 因为它的职责比较多，我们暂且称其为：胖 BFF。 瘦 BFF 的好处是： 端到端交付，前端开发人员直接使用后端领域服务的 API 文档 开发效率高，避免多编写一层 BFF 减少一次集成 对应的，瘦 BFF 的弊端可想而知： 没有编排层，服务之间相互依赖 开发团队规模和技能 瘦 BFF 相对容易开发和维护，适合小型开发团队或技术能力有限的团队。而胖 BFF 需要更高的技术水平和更多的开发资源，适合有经验的大型开发团队。 3.
41120编辑于 2024-12-06
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号