Enable javascript in your browser for better experience. Need to know to enable it? Go here.
发布于 : Apr 13, 2021
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。 了解更多
Apr 2021
试验 ? 值得一试。了解为何要构建这一能力是很重要的。企业应当在风险可控的前提下在项目中尝试应用此项技术。

随着TypeScript成为前端开发的常用语言以及Node.js成为BFF的首选技术,我们看到 “UI/BFF共享类型”正在被越来越多地使用 。在这种技术中,一个类型定义不仅会被使用在前端请求返回的数据中,也会被使用在服务端用来满足这些查询。由于这种做法会跨越流程边界产生不必要的紧密耦合,因此我们通常会对这种做法保持谨慎。但是,许多团队发现这种方法的好处胜过耦合带来的风险。当一个团队同时拥有UI和BFF代码时,通常会将组件存在同一个代码库中,这个时候BFF模式是最有效的,因此UI / BFF对可以被看作是一个单一的内聚系统。当BFF提供强类型的查询时,可以针对前端的特定需求量身定制查询结果,而不必重用一个通用的实体,因为这些通用实体需要为很多消费者服务因此会包含很多不必要的字段。这样可以减少意外地将不必要的数据暴露给用户的风险,防止对返回的数据对象进行错误的解释,并使查询更加表意。当使用io-ts来增强运行时类型安全性时, 这种实践特别有用。

下载第27期技术雷达

English | Español | Português | 中文

获取最新技术洞见

 

立即订阅

查看存档并阅读往期内容