yog,简单易用的node框架


风风火火又是一个多月过去了,炎热的北京夏天热得每个人都很浮躁,空调吱呀吱呀,有同事就咆哮大骂起来了,殊不知空调这玩意儿也能让TA生气。说偏了,回到正文。

就在着炎热的夏天,项目组开发了一套node的开发框架,yog

yog解决了什么问题呢?

  • 中间件维护问题
  • 路由
  • bigpipe支持
  • mvc封装
  • 目录规范
  • 开发模式

中间件维护问题

用过express的人都知道,中间件维护起来确实挺麻烦;需要以这样

app.use(static());
app.use(router());

硬编码的方式挂载中间件;这样假设某一天需要添加中间件时,还得考虑要加载哪两个的中间;所以yog利用配置文件配置进去。

{
    "middleware": {
        "urlencoded": {
            "enabled": true,
            "priority": 50,
            "module": {
                "arguments": [
                    {
                        "extended": true
                    }
                ]
            }
        }
    }
}

上面就是一个例子,中间件urlencoded以这样一个方式配置到框架中;

路由

说到路由,假设用express的方式解决的话是如下这个样子的;

app.get('/xxx', requestHandle);

如果按照这种方式,所有的路由可能需要写到某一个文件里面;就比如django就是配置在一个文件里面的,这样的好处是所有的路由情况都可以一目了然; 但项目大了以后放到同一个地方确实会不方便,一般会选择使用一些规则来命中某一个Action,比如根据URI的信息来做匹配执行代码,这种方法很多框架都使用;

yog里面结合了两种方式,先用规则的方式命中某一个controller,然后在controller中书写关于这个controller的路由规则,比如:

http://127.0.0.1/user/get

/user/ 命中 controllers/user.js

//user.js

module.exports = function (router) {
    router.get('/get', function (req, res) {
        //balabala...
    });
};

在项目启动的时候,会扫描controllers目录下的文件,全部挂载到运行环境中;

通过对中间件的处理以及router的处理;入口文件就相当简单了;

var app = require('express')();
var yog = require('yog');

app.use(yog());
app.listen(4000);

bigpipe支持

关于BigPipe,前面已经写了一篇博文说明网页加载优化方案:bigpipe,bigrender,lazyrender

以前在PHP里面实现,无法做到并行获取数据,然node就不一样了,可以随意并行,所以yog对bigpipe的支持是很完整的;它可以控制任意一小块页面输出,可以很方便的做性能优化。

那是如何实现的呢?

具体的实现可以阅读源代码yog-bigpipe。大概总结是这样的;

  • 使用模板的钩子标识每个需要pipe出来的区域
  • 渲染时把这些区域抠出来,留个占位符<div id="id_100"></div>
  • 后获取pipe区域的内容,并输出给浏览器
  • chunck输出

具体使用可以下载示例,跑一把就知道了。

MVC封装

说到此处,yog其实只负责了viewcontroller层,因为按照经验来看,model层迁移node阻力很大,暂时没有对这层的覆盖,后续会陆续搞定这层;

MVC封装比较简洁,controller兼职管理router的职务,并渲染view

目录规范

这节说一下目录规范,其实这些都在文档中有详细的说明;

➜  yog-app git:(master) ✗ tree -L 1
.
├── config
├── controllers # controller
├── models # model
├── views  # view
├── public    # 静态资源文件夹
└── server.js # 入口文件

开发模式

如图,述说开发模式,不得不上一幅图;

  • RD 后端开发
  • FE 前端开发

A开发模式

FE写完页面,然后把写好的页面交给RD进行模板化,也就是模板这个东西在RD手上,也就是归于后端业务逻辑

这种模式的不好的地方是,前端页面展现显然是经常会变化的,那么来回这么折腾,费时费力不说还费钱;

不过貌似很多公司都是A开发模式

B开发模式

为了解决上面的问题,出现了B开发模式,B开发模式是这样的;FE负责了写模板这个事情,每次迭代都很方便,有UI修改,只需要上模板就行,这时候一个频繁的工作由FE完成;

当然,这种开发模式也是有问题的;比如RD没有开发完成,FE就没有数据来测试自己的代码了;这时候需要一套本地模拟环境的工具;比如现在的fis-plus就完美模拟了线上环境;

还有一个问题是啥呢,那就是每次还需要跟RD对接口,对数据结构,每次添加修改点数据也很麻烦;

到后来就出现了C开发模式

C开发模式

C开发模式就是建立大前端,FE负责UI层后端逻辑以及前端相关所有事物,这种模式相当不错,处理问题或者添加功能只需要FE来搞就行,没有了额外的沟通开销,开发顺畅了不少。

但,也许FE需要学习一门后端语言,当然这个不是问题;

yog 专提供给FE同学的后端UI开发框架,不巧语言也是FE同学熟悉的JavaScript(nodejs),这样似乎可以方便的使用C开发模式