最近在做一个网页静态化的工具, 后台用的 node+ express, 但是没有用 DB, 主要是考虑到业务的数据量实在是小的可怜, 就是几个配置和日志文件 , 所以我把数据用 fs.writeFile 直接写到 json 文件中, 然后每次读都直接 fs.readFile 读出来
但是这样子貌似是有些简陋, 其中完全可以把 文件读取相关的封装起来, 然后提供对象读写接口 类似于 get() put() remove() 等接口,
既然是读多写少 , 那么上面的方案肯定是有优化点的, 比如写操作, 可以直接调用 fs readFileSync 同步的写, 反正量少 而读是大头, 经常一个 cgi 请求在返回之前可能会有好几个读的操作 , 那么我这样子直接调用readFileSync 是不是有些简单粗暴
说干就干, 搞一个 file-storage 的内部组件
首先它是一个组件, 其次, 它与具体的业务逻辑是解耦的, 业务逻辑经常需要调用底层逻辑或者一些系统通用逻辑, 然而每次都需要去编写这些接口和代码是没有必要的, 这时候中间件就可以出场了.
具体的场景是可以看做如下: 前端业务需要某个服务, 我无需关心提供这项服务的具体底层逻辑, 只需要通过中间件获取到结果就好了
我们开发了一个很简单 webserver, 现在需要把不同 url 的请求路由到不同的业务处理 模块, 一开始我们的请求路径很少, 直接用 switch 语句就可以应付了, 后面随着路径越来越多, 每次都要改这个往这个 switch 加 case, 后面需求越来越变态了, 竟然要根据url路径中的参数(如用户 id 或者商品 id)路由到不同的 handler 方法, 显然我们的路由逻辑越来越复杂了
作为一个开发者, 关于如何处理好的路由的显然不是我最关心的(我只想好好地写业务代码), 那么这时候如果有一个第三方(路由中间件), 只需要传入请求的匹配规则, 对应的 handler 函数, 至于如何把请求路由到正确的 handler 中, 那是路由中间件的事情了, 之后就可以愉快的写业务代码了
最近开始接触到公司内部的一个 nodejs 的框架 TSW, 也看了很多内部论坛是上关于 tsw 文章 , 在学习开发使用的过程中, 也对部分技术框架的设计存有疑惑.
但是, 就目前 tsw 在公司内部大范围的使用的情况来说, 接入完善的公司内部业务模块以及与走织云发布流程, 在使用上很好的承担了许多业务.
由于个人的兴趣爱好,在业余的时间也打算研究一下如何去实现一个类似的框架以及开发流程, 本系列文章也算是自我学习的一个记录,加深理解.
此次文章打算分上下两篇:
上篇: 主要介绍如何去实现一个类似 tsw 的集合开发运维一条龙服务的框架.
下篇: 尝试一下开发运维模式–node与服务容器化
友情链接: tswjs.org, tsw 的官网的文档还是写的挺幽默风趣的,就是内容比较少, 需要大家边用边摸索
