跳到主要内容

· 阅读需 5 分钟
Harry Chen

2024 新年快乐。

升级请参考 如何更新 Midway 中描述,请不要单独升级某个组件包。

本次 3.14 版本,重写了 Cache 组件,同时也带来了一些新的特性,我们将一一介绍。

全新的 CacheManager 组件

这一版本,Midway 将底层依赖的 cache-manager 模块升级到了 v5 版本,由于存在 Breaking Change,启用了一个新的 @midwayjs/cache-manager 组件,原有 @midwayjs/cache 组件不再更新。

在新组件中,提供了装饰器 @Caching 用于快速缓存函数结果。

比如:

@Caching('default', 100)
async invokeData(name: string) {
return name;
}

那么,在多次调用时就会缓存返回值,如果超时,则会返回新的值。

await invokeData('harry'); // => harry
await invokeData('harry1'); // => harry
await invokeData('harry2'); // => harry
await sleep(100);
await invokeData('harry3'); // => harry3

这在一些性能敏感的场景会非常有用。

此外,@Caching 装饰器还支持多级缓存,如果一个缓存实例配置了多个 Store,那么它将自动根据缓存的顺序进行处理。

最重要的一点,组件通过新设计器的 createRedisStore 方法支持复用 Redis 组件的配置了。

import { createRedisStore } from '@midwayjs/cache-manager';

// src/config/config.default.ts
export default {
cacheManager: {
clients: {
default: {
store: createRedisStore('default'),
// ...
},
},
},
redis: {
clients: {
default: {
port: 6379,
host: '127.0.0.1',
}
}
}
}

这下不再需要配置 Redis 多遍了。

更多功能可以接着查看 文档

Swagger 组件的全新渲染方式

由于之前的版本无法传递 swagger-ui 参数,这个版本设计了一组新的 UI 渲染方式,尽可能的帮助开发者自定义 UI。

现在,通过 renderSwaggerUIDistrenderJSONrenderSwaggerUIRemote 方法,你可以选择自己喜欢的方式进行渲染。

// src/config/config.default.ts
import { renderSwaggerUIRemote } from '@midwayjs/swagger';

export default {
// ...
swagger: {
swaggerUIRender: renderSwaggerUIRemote,
swaggerUIRenderOptions: {
// ...
}
},
}

只要网络环境允许,即使不再引用 swagger-ui-dist 包,也可以通过 CDN 资源加载 UI,进一步减轻服务端压力。

也可以仅输出 Swagger JSON 内容,不提供 UI,这都可以根据业务随心配置。

服务工厂实例支持优先级

这一版本可以针对创建出的实例设置不同的实例优先级。

比如:

// config.default.ts
import { DEFAULT_PRIORITY } from '@midwayjs/core';

export default {
redis: {
clients: {
instance1: {
// ...
},
instance2: {
// ...
}
},
clientPriority: {
instance1: DEFAULT_PRIORITY.L1,
instance2: DEFAULT_PRIORITY.L3,
}
}
}

实例优先级不影响实例本身的功能,仅对实现了优先级判断的外部逻辑生效。

比如在健康检查时可以根据优先级进行忽略,低优先级的实例等价于弱依赖,会跳过健康检查。

这一功能目前仅有 HealthService 在使用,理论上别的逻辑也可能会用到,我们期待更多的可能性。

更多的变化

  • mikro-orm 于 2024.01.08 日发布了 v6 版本,现在 @midwayjs/mikro 组件也可以配合 v6 版本使用了
  • @midwayjs/redis 增加了基于实例优先级的健康检查逻辑
  • 服务工厂增加了 getClients()getClientKeys() 方法,用于快速迭代实例
  • 修复了 swagger 组件 ApiOperation 相关的一些问题
  • mwtsc 工具修复了 windows 下开发的问题
  • 文档的进一步精简,“其他” 菜单合并到了 “使用文档” 菜单中

此外,还有一大批依赖进行了更新,更多可以参考我们的 ChangeLog

· 阅读需 5 分钟
Harry Chen

升级请参考 如何更新 Midway 中描述,请不要单独升级某个组件包。

在双十一大促之后,Midway 迎来了 3.13 版本。

这个版本主要调整了内置的 logger 模块,使其可以支持 v3 版本的 logger 库。

Breaking

  • 1、未声明 @midwayjs/logger 依赖的用户的日志会出现意外错误
  • 2、日志的配置定义可能丢失

这两个问题的解法在最后描述。

Feature

1、日志库升级到 v3

经过一些时间的重写,Midway 搭配的 logger 库也升级到了 v3 版本,在 v3 版本中,我们移除了 winston 依赖,重写了整个 logger 模块,性能几乎翻了一倍。

bundlephobia 中也能看到很明显的变化,代码的精简,使得运行更高效,代码更受控。

从这个版本开始,Midway 的日志库可以选择使用 v2 或者 v3 的日志库,注意两者的配置是不同的。

如果你想查看两个版本的变化,可以点击 这里

如果你希望升级到 v3 版本的日志库,我们的 文档 也已经准备好了。

提示

注意,大版本升级请谨慎,尽可能验证功能点。

2、内置服务新增 HealthService

Midway 一直没有提供内置的健康检查方案,在这一版本,终于 设计 了 HealthService 这一内置的检查服务。

HealthService 用于提供检查 API,在不同的情况下可以自行接入检查自定义组件的状态,文档在此

同时,我们的 Configuration 生命周期也增加了一个 onHealthCheck 的阶段,用于在每次检查时执行,文档在此

这一功能目前还没有组件接入,我们将在后续的版本中逐步完善它。

其他的一些变化

  • 1、jwt 组件的配置提供更多的选项,比如 sign,verify,decode 等选项
  • 2、jwt 组件导出了默认的 jwt 实例,你可以从上面获取到一些内置的错误实例,方便过滤器拦截
  • 3、http-proxy 组件现在可以通过 enable 配置来关闭了,这样你可以自行引入中间件做更多的自定义处理
  • 4、在 web 框架中,context.state 的类型现在也可以自定义了,这在文档中也进行了更新
  • 5、修复了 static-file 组件的 namespace 不正确的问题
  • 6、修复了 framework 加载时主框架顺序不固定的问题

解决方案

1、日志库丢失的方案

由于大部分脚手架我们都已经引入了日志库依赖,一般来说不需要处理。

如果未引入日志库,框架会在启动时报错,只需要在 package.json 的依赖中写入即可。

"dependencies": {
+ "@midwayjs/logger": "^2.19.2",
},

注意,只有上述最新版本的日志库才兼容 v3.13.0 以上的 @midwayjs/core

2、日志的配置定义丢失

由于 ts 类型合并需要在项目中显式声明一次,你需要在 interface.ts 中加入下面的代码。

+ import type {} from '@midwayjs/logger';

/**
* @description User-Service parameters
*/
export interface IUserOptions {
uid: number;
}

这样在 src/config/config.default.ts 中配置 midwayLogger 字段时,日志库的定义会恢复。

· 阅读需 3 分钟
Harry Chen

升级请参考 如何更新 Midway 中描述,请不要单独升级某个组件包。

在经过了几个月的努力更新之后,Midway 迎来了 3.12 版本,这是一个改动比较大的版本。

Breaking

从 v3.12.0 开始,Midway 移除了 Node.js v14 的 CI,原因请参考 这里

Features

1、ESM 的支持

从 v3.12.0 开始,midway 支持创建 ESModule 项目,使用时和传统 CJS 项目会有所不同,由于时间紧迫,我们没有针对所有的组件进行测试,如有兼容性问题,请提交 issue。

此外,由于原有的工具体系已经无法很好的兼容 ESM 环境,为了减少维护成本,我们启用了一套全新的工具链,后续普通 CJS 项目也会统一到这一套上来。

更多细节请查看 ESM 文档

2、FaaS 架构变更

从 v3.12.0 开始,Midway FaaS 使用全新的一套架构支持现有的 Serverless 平台,这一部分后续将会在文档中体现。

主要的变化:

  • Midway 不再提供 “应用部署到弹性容器” 的兼容方案,如果平台支持使用传统应用部署 Serverless 容器,可以直接使用标准项目部署
  • Midway 不再提供 f.yml 的维护工作,也不再提供部署功能,仅提供将现有函数信息写入平台配置的能力,所有的函数部署将由平台自己的工具进行部署
  • 移除了原有通过 @midwayjs/serverless-app 启动和开发的模式,作为替代,将使用 @midwayjs/fc-starter 来进行开发

其他的一些变化

  • 1、添加了 ctx.getApp() 方法,可以从 ctx 拿到自己 app,打通了整条从 framework,到 app 和 ctx 的链路

  • 2、core 中的 httpClient 现在支持了所有的 http method

  • 3、增加了一个内部跳转 URL 的 api,ctx.forward

  • 4、IoC 容器增加了一个获取对象作用域的 API,container.getInstanceScope(xxx)

依赖更新

具体可以查看 Changelog

· 阅读需 2 分钟
Harry Chen

最近一段时间,我们发现越来越多的库移除了 Node.js v14 的支持。

有些库是升级的大版本,有些库仅仅只升级 minor 版本,这使得依赖他们的业务、模块乃至框架都很难信任社区的 SemVer 版本约定了。

为了保持 Midway 的单测正常运行,从 v3.12.0 开始,Midway 移除了 Node.js v14 的 CI,这意味着我们无法测试 Node.js v16 以下社区库的兼容性,只能靠社区库更新的 Changelog 以及我们的经验来保证。

如果我们发现某些库只支持特定版本的 Node.js,我们会在 package.json 中进行版本限制,如果你发现某些库的版本更新无法在低版本 Node.js 中运行,且 Midway 的组件没有进行限制,请通知我们。

最后再次提醒,如果没有强需求,请使用 Node.js v16 以上版本。

· 阅读需 3 分钟
Harry Chen

升级请参考 如何更新 Midway 中描述,请不要单独升级某个组件包。

很高兴给大家介绍我们的 3.11 新版本。

安全性更新

Upload 组件增加了安全性性能,在 file 上传模式下,我们发现在某些情况下文件的后缀和实际内容不匹配,导致可能会在服务器被动执行的安全性漏洞。

新版本我们增加了一个 MIME 配置,可以在上传时检查扩展名之外,额外检查 MIME 的类型,会更加安全。

export default {
// ...
upload: {
// ...
// 仅允许下面这些文件类型可以上传
mimeTypeWhiteList: {
'.jpg': 'image/jpeg',
}
},
}

更多细节可以查看我们的 Upload 组件

New Feature

精细化的 Mock 能力

基于框架新提供的 @Mock 装饰器,可以方便的在不同的阶段进行数据模拟。同时作为逻辑的一部分,这个功能可以在开发和测试期被自动执行,方便用户的开发期模拟数据。

文档请参考 数据模拟

中间件的 Match/Ignore

Middleware 的功能进一步增强,match 和 ignore 现在可以是 stringregexpfunction 或者他们的数组组合形式。

本地定时任务组件

之前我们提供了 bull 组件,用于分布式定时任务,在某些场景下,我们依旧需要单机的定时任务来赋值完成一些事项,原有的 task 组件实现了 cron 的部分,我们将其分离为 cron 组件,继续提供能力支持。

文档请参考 cron 组件

标签组件

一种抽象化的服务端能力,用于数据筛选和处理。

文档请参考 标签组件