Node 上层框架的技术选型

hot_pot_Leo
3,601 阅读3分钟

意外，这个是草稿来的，也不知道如何撤回，尴尬的是死。

前言

公司Node 的诉求：调用微服务，减少基本错误，

预期:

    1. 减少基本错误
    • 1.1 类型错误 => 类型推断
    • 1.2 数据返回问题 => 类型推断
    1. 提高可维护性，健壮性
    • 2.1 注释
    • 2.2 类型推断 => 类型推断
    1. 降低耦合
    1. 统一规范

框架

  • Sails.js
    • 中文文档
    • 缺点：中文社区不行，文档绝大多数都还是英文 | 有点重
  • Hapi.js - 文档不太行，并且纯英文
    • 中性：router/service/controller 在一起的。
    • 缺点：17年口凭还不错，后来说CNode社区表示性能不行了。
// hapi.js API书写
let speech = {
    value: 'welcome',
    set (val) {
        this.value = val
    }
}
server.route({
    path: '/api/welcome/{name}',
    method: 'GET',
    handler (request) {
        return {
            code: 200,
            success: true,
            data: {
                msg: `${speech.value} ${request.params.name}`
            }
        }
    }
})
server.route({
    path: '/api/speech',
    method: 'POST',
    handler (request) {
        speech.set(request.payload.word)
        return {
            code: 200,
            success: true,
            data: {
                msg: `speech is *${speech.value}* now`
            }
        }
    }
})
  • LoopBack.js
    • 中文文档
    • 缺点：嵌入的东西有些多，包括但不仅仅有安卓，IOS的SDK包处理等等
  • Moleculer - 没中文
  • Derby.js - 有点low
  • Nest
  • Midway
  • Thinkjs
  • Chairjs - 开源出来的部分不成熟

nestjs

midway

thinkjs

1. 特性

Midwayjs Nestjs Thinkjs
基于 egg express koa
TS 支持 支持 支持
特点 IOC IOC 开箱即用
库生态系统 egg生态 express生态 koa生态
团队 阿里 个人 360
社区 活跃 活跃 较活跃
学习曲线 偏高 高 较低
文档 完善 完善 完善
工具 多 较多 一般
历史 egg生态 express生态 koa生态
满足业务 满足 满足 满足

2. 学习曲线

  • Midwayjs：和nest差不多，大致需要了解 Proxy, Reflect, Symbol, 装饰器，六个设计原则。
  • Nestjs: (感觉就是Spring，如果对Java了解不多的话，可能有点难)
    nestjs
  • Thinkjs：和 egg 体验类似，相比egg，规范了很多开发规则，从而达到开箱即用。

3. 部署：

Midwayjs 部署

nestjs 部署: 需要自行处理，似乎有点坑？

Thinkjs 部署

个人体会

  • midway 并没有给我太多惊艳的地方，仅仅只是给了更多的语法糖。

  • nest 确实更加完善，但是个人觉得学习成本较高，Spring 设计思路。

  • thinkjs (thinkPHP ???)相比 egg，说是说thinkjs更加切合直接写业务的框架, 相比与 egg感觉差别不大，就像 thinkjs 返回成功就是 this.ctx.success({ })

egg thinkjs 谁好
启动器 egg-cluster PM2 egg
分层 较好 更加细腻 thinkjs (egg 可以通过抽离解决)
是否开箱即用 还需要封装一些东西(统一返回等) 开箱即用 thinkjs (egg需要自行封装)

个人总结

为了简化我们的开发诉求，还是使用 egg 生态。 因此，需求量不是很复杂，可以选择：

  1. egg的ts版本，通过工具和插件完善
  2. 基于 midway 封装工具或中间件解决

规范

  • 请求返回规范
    • 一个请求的情况（包括成功是失败）
    • 多个请求的情况（包括成功和失败）
  • 业务书写规范
    • service 层职能要纯净
    • 必须有完整的格式化方案(eslint+tslint+prettier)
  • 通用处理尽可能使用中间件解决。
  • 需要处理多请求有一个报错多解决方案。
  • 日志的打印规范。(通用，无需业务处理)
avatar
文章
阅读
粉丝