程序员的核心痛点
工作中接触不到复杂问题，基本上都是重复板砖，在工作这几年中没有什么成长。 在小公司，前端就两三个人，根本就接触不到，所以都接触不到外面的东西，需要跳出原本的圈着，所以要跳出圈子，看看外面的人是怎么玩的。
方向和思路
请求库的封装
axios 虽然很成熟，但是只是要给基础库，没有提供诸多的上层功能 1，请求重试 2，请求缓存 3，请求幂等 4，请求串行 5，请求并发
底层设计思想 请求(axios,fetch,xhr)底层 -> 方法层 -> 上层应用
设计的目的要使三者使用独立，任何一层修改不影响其他层，降低耦合
使用DIP(依赖倒置原则)，需要结合ts的实现 1，ts定义接口，返回统一的request 2，方法层，定义请求缓存的方法，配置化参数，key和组成，和value的存储，失效时间多个参数，内部实现归一化处理
3通过接口文档生成前端接口模板
比如发布文章，需要幂等性：isMD，生成对应幂等的接口调用
用node实现模板生成
node 作用 1，BFF层 2，工具(node,rust)
方案选择 首先我考虑的是实现的必要性。 前端本身存在诸多的请求库,像成熟度比较高的axios,但它们都是一些基础库,没有提供上层功能比如请求并发、请求重试、请求幂等这些都没有。 另外像一些上层的请求库倒是有这些功能,比如VueRequest,SWR,但它们都和具体的框架绑定了并且没有提供请求的基础功能，而且它们之间使用风格和功能点都有差异 更重要的一点是,市面上的公共库不可能提供基于公司内部协议的封装。 所以我不得不考虑重新实现基于公司内部业务的通用请求库。 技术实现 在实现层面，我首先考虑的是请求库的整体结构。 我把请求库分为三层,从下到上依次是请求基础库,负责发送请求的基本功能,然后是请求核心库负责实现各种上层逻辑,比如并发等等,最上层是请求业务库,负责在代码层面封装公司内部协议。 在结构上,考虑到请求基础库的具体实现方式可能有变动,必须由xhr换成axios或者fetch,为了减少变动对上层代码造成的改动,我应用DIP原则,参考了后端的1OC和Dl,让核心库不依赖具体的请求基础库,核心库仅提供TS接口,请求基础库可以基于接口提供不同的实现方式,在业务库注入具体实现即可,这样一来,就彻底隔离了请求的具体实现,将来实现变动后可以轻易的接入。 另外,上层业务库由于深度绑定公司内部的接口文档,而我们项目中的接口数量非常庞大,为了减少开发和维护成本,我用node实现了一个自动化工具,通过解析接口标准文档,自动为每个接口生成请求样板代码,并且考虑到某些样板代码可能不符合实际需要,我制定了一种可以基于样板代码打补丁的开发方式。这样既减少了开发量，同时也保证了灵活度。 落地效果 以上就是大体情况,里面细节还很多就不一一列举了。后续我还在请求库基础上进一步封装了针对各种前端框架的请求库,那都是很薄的一层,比较简单就不详细说了。 整个请求库的落地效果还是很亮眼的,业务开发人员再也无须关心任何的请求,只需调用请求库的业务函数即可,无须关心内部的并发、幂等这些复杂问题,这些事情对业务开发人员完全无感。 整个请求库为公司的业务开发带来30%的效率提升,并依靠自动生成的样板代码,减少了50%的接口联调的时间。
