随手一笔

yog，简单易用的node框架

Jul 30, 2014
1 minute read

风风火火又是一个多月过去了，炎热的北京夏天热得每个人都很浮躁，空调吱呀吱呀，有同事就咆哮大骂起来了，殊不知空调这玩意儿也能让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其实只负责了view和controller层，因为按照经验来看，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开发模式。