江苏龙网

  1. 主页 > 生活百科 > >

大前端不是全栈( 二 )

大前端


其次，精力之余拓展边界，Nodejs 全栈是一个不错的选择，进入后端研发深水区，选择其他传统的后端语言（java、go 等）解决关键性能问题也是需要考虑的 。不局限在一个语言技术，因地制宜，核心是能解决问题 。
3前端中台只是解决问题的一种方式
互联网的产品变化较快，很多团队 / 企业在很多领域都有投入，那这些业务之间的一些共同技术建设，如能复用起来能降低业务冷启动成本，提升新业务研发效率 。中台建设也是基于这个核心诉求，基于中台能力建设，能做到跨业务、跨领域技术复用，缩短新业务初创时间并节省资源 。同时，复用的前提是解耦，能做到通用的能力和业务个性化能力完全解耦 。解耦的架构设计，可以降低系统本身的维护成本，增强体统健壮性 。解耦的设计能更好的业务之间复用 。
大前端中台建设类似，问题存在就得用方案去解决，中台建设是其中一种方式（大中台、小前端） 。中台不是万能的，不能解决所有问题 。技术复用带来如何满足个性化诉求的问题，需要进一步思考如何更好地解决各个业务之间个性化能力 。从火热到冷静也更能反映技术本身的演进，冷静并不是代表放弃，而是面临新的问题如何进一步解决 。
前端中台的分层架构
回到前端工程化的能力，针对前端中台来说，一定程度上工程化就是在前端中台的事情 。把前端通用的一些规范、工具、能力、组件统一化中台建设，提供不同的业务支持 。
因此从设计上，应该包含基础层，统一网关，组件层，业务层 。基础层提供基础的工具和能力支撑（诸如全链路监控基础工具）、统一网关（统一路由分发、业务个性化插件）、组件层（基础通用组件、组件二次开发体系、组件组装、智能研发）、业务层（业务逻辑与业务组件等） 。
每一个环节都很关键，能够把我们业务开发的基础、插件、组件、业务完全隔离开来，尽可能做到不同复用 。
中台的拆分与合并，我们该遵循怎样的原则
架构解耦和拆分工作，本身就是一个度的把握 。原则上既要解决逻辑耦合，又不能过度设计，允许一定程度的冗余 。在开发过程中，要看到实际业务之间可行的复用能力、模块、组件，而非理想情况下的复用 。基于实际的复用诉求，进行业务提炼解耦，并做一定程度的超前思考（原则就是做有意义的拆分） 。
前面提到的架构设计中，统一网关层插件、组件二次开发就是要解决这些问题 。支撑不同业务自定义插件（或许这些插件之间存在部分重复，但不影响整理架构复用）、组件二次开发进行复用，能做到整体上架构一致和不用业务之间个性诉求 。
前端中台的建设实践
上文已经提到了刘恒兵老师团队的前端中台方案和设计 。那么其中遇到的问题主要还是怎么尽可能复用以及业务个性化诉求 。我们经常会超前研发设计一些拆分与解耦，但后续实际过程中发现是一个伪需求 。比如说组件，很多时候提炼的业务通用组件发现后续业务并不能直接复用，业务个性化诉求太多了 。
方案上，通过组件二次开发体系建设，解决这类问题 。我们发现虽然业务组件不能直接复用，但又能复用其中一部分，直接使用不满足诉求，重新开发浪费精力 。其实这里核心的问题并不是复用，而是复用的效率，最后搭建二次研发体系方便研发能够快速二次开发，提升二次开发效率，达到复用的目的 。
4回顾与展望
【大前端不是全栈】2020 年，疫情下的“前端”
回顾 2020，我印象比较深的有三件事：一是 Type 的大范围普及，二是工程化的发展，三是全栈深水区 。
相比于 2019 年，2020 年 Type 已经深入人心了，各前端框架对 Type 的支持进一步推动了 Type 的应用和普及，语言层面的发展能非常快速的促进一个领域的发展，正如 Node.js 促进前端领域发展一样 。
2020 年的疫情给整个社会带来的新的挑战，企业对于研发效率的迫切需求进一步促进了工程化领域的发展 。以前工程化对于很多研发人员仅为了解或者认知仅限于工程构建 。疫情期间的工程化已经演变为对企业效率的诉求，各个领域都需要工程化体系帮助远程办公、移动办公提升效率 。
2020 年，大前端全栈逐渐进入深水区，不再是仅仅满足基本的 SSR/BFF 等诉求 。对 Node.js 新的期待逐渐变多，承担更多的场景 。中台化后统一的服务、网关都是需要 Node.js 去承担，因此带来的服务质量、容灾等各方面诉求就对 Node.js 提出了新的要求，全链路监控、Serverless 服务质量 / 性能等都需要进一步建设和完善 。当然，这些挑战也会进一步促进 Node.js 的生态发展 。


推荐阅读


上一篇：数据库同步软件DBSync的设计与实现

下一篇：邦东古树茶地理位置,邦东奇韵