关于 Serverless Devs Plugin机制的讨论

[anycodes]

在 Serverless Devs 项目开始之初，我们确定了 Serverless Devs 的 Package 有三种形式：

• 应用
• 组件
• 插件

所谓的应用，指的就是一个 Serverless 项目，一般可以用一个 Yaml + Code 表示一个应用；而所谓的组件，则是应用操作过程中所需要的一些能力支持；我经常把这个比喻成游戏机和游戏卡：

Serverless Devs Cli就是一台游戏机，而各种游戏/功能，被放在不同的游戏卡中，通过插入不同的游戏卡，可以玩不同的游戏，所以一个应用可以通过插入不同的组件，实现不同的功能。例如某应用的描述如下：

edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
name: FullStack       #  项目名称
access: xxx-account1  #  秘钥别名

vars: # [全局变量，提供给各个服务使用]
  logo: https://image.aliyun.com/xxxx.png

services:
  nextjs-portal: #  服务名称
    access: xxx-account1  #  秘钥别名，如果和项目的access相同，可省略
    component: vue-component  # 组件名称
    props: #  组件的属性值
      src: ./frontend_src
      url: url
    actions: # 自定义执行逻辑
      pre-deploy: # 在deploy之前运行
        - run: s exec -- publish  # 要运行的命令行
          path: ./backend_src # 命令行运行的路径
        - run: s build  # 要运行的命令行
          path: ./backend_src # 命令行运行的路径
      post-deploy: # 在deploy之后运行
        - run: s clean
          path: ./frontend_src

  assets:
    component: static
    props:
      cache-control: "public, max-age=604800, immutable"
      www: "./public"

  express-blog:
    component: express
    props:
      app: ./express-blog
      url: ${vars.domain}
    actions:
      pre-deploy:
        - run: npm run build
          path: ./express-blog

  gateway:
    component: serverless-gateway # 路由组件：HTTP URL和服务之间的映射规则
    props:
      routes:
        - route: /~assets
          value: ${assets.output.url}
        - route: /
          value: ${nextjs-portal.output.url}
          index: index.html
        - route: /~portal
          value: ${nextjs-portal.output.url}
          inex: index.html
        - route: /~blog
          value: ${express-blog.output.url}

在这个应用中可以看到有三个模块，分别是：

• nextjs-portal，使用了vue-component组件
• assets，使用了static组件
• express-blog，使用了express组件
• gateway，使用了serverless-gateway 组件

整个应用，通过四个部分组成，部署了前后端业务，API网关资源以及相关静态资源的处理。

但是在实际应用过程中，我们发现，单纯的组件 + 无状态的钩子，没办法满足用户们日益增长的需求，那么我们最初的插件逻辑，就逐渐的“提上”来了：

插件：一种在Actions中表现的，对上下文进行处理的能力，在上面的应用中，我们不难发现：

  express-blog:
    component: express
    props:
      app: ./express-blog
      url: ${vars.domain}
    actions:
      pre-deploy:
        - run: npm run build
          path: ./express-blog

在express-blog中，有一个actions，actions表示的是在该模块执行前后的一些自定义操作，例如：

• pre-***: 在执行***前的操作
• post-***：在执行***后的操作

那么插件是什么？

如上所示，在Actions中，有一个pre-deploy，内容是：

 - run: npm run build
    path: ./express-blog

表示的是在执行deploy命令之前，在目录./express-blog下面，进行npm run build操作，除了这种单纯“钩子”行为，Serverless Devs还将会支持一种Plugin的模式，与这种钩子行为不同的是：

• run：更多是一种钩子，相对来说是无状态的，例如执行npm install等命令，实际上就是一个shell指令；
• plugin：是一种有状态的操作，会将当前项目的inputs信息传入给该plugin，完成之后，会讲该plugin的返回作用给下一个状态；

整个逻辑是这样的：

所以，可以认为，Plugin机制是有状态传递的，常见的应用如下：

• 本地有一段代码，但是部署之前我可能要做一下转换，可以通过这种plugin的模式转换
• 本地发布之后，想要直接发布版本，可以用这种模式处理

解决当前常见的那些问题？

• 如果用户嵌套使用s，在actions里面依旧写了s nas upload等，而在外面写了s deploy -t *** -a *** ，此时外面的内容不回传给s nas upload，导致行为表现不一致；
• 用户往往需要针对当前项目做一些事情， 但是在actions里面写了s version publish，会导致所有的模块执行s version publish，和预期结果不一样；

plugin的使用方法：

  express-blog:
    component: express
    props:
      app: ./express-blog
      url: ${vars.domain}
    actions:
      pre-deploy:
        - run: npm run build
          path: ./express-blog
        - component: fc nas upload
      post-deploy:
        - component: fc version publish

deploy后，项目的执行逻辑：

1. 在目录./express-blog下执行npm run build
2. 执行 fc组件，调用nas方法，入参inputs:

{
    "command": "", 
    "project": {
        "projectName": "", 
        "component": "",
        "provider": "",
        "access": ""
    },
    "credentials": {},
    "prop": {},
    "args": "",
    "argsObj": []
}

4. 执行express组件的deploy方法，入参inputs：

{
    "command": "", 
    "project": {
        "projectName": "", 
        "component": "",
        "provider": "",
        "access": ""
    },
    "credentials": {},
    "prop": {},
    "output": {}, # 前一个插件的输出；
    "args": "",
    "argsObj": [],
    ""
}

6. 执行 fc组件，调用version方法

{
    "command": "", 
    "project": {
        "projectName": "", 
        "component": "",
        "provider": "",
        "access": ""
    },
    "credentials": {},
    "prop": {},
    "output": {}, # 前一个插件的输出；
    "args": "",
    "argsObj": [],
    ""
}

另外，应该提供一个方法，更新prop内容，例如插件fc nas upload调用了该方法，对prop内容进行了更新，那么这个内容将会作为新的prop传给下一个流程

Q：为什么叫做插件，但是在yaml中用component表达？
A：主要是担心过多的概念对用户造成负担，所以取消插件的概念，换成在actions里面直接用组件的逻辑。
Q：这个内容上线之后，叫做什么？
A：目前的想法是仍然叫做组件，只不过是一种在actions中直接使用组件的方法。

[anycodes]

综上所述：需要提供的内容包括：

1. actions中直接使用component的方法
2. core中提供一种可以修改原prop内容的方法

[heimanba]

这里是 plugin吧

[anycodes]

是的，这里就是我们的plugin机制，但是为了降低理解成本，打算将plugin机制换一种说法。

主要是担心过多的概念对用户造成负担，所以取消插件的概念，换成在actions里面直接用组件的逻辑。可以解释成，在actions中直接使用某个组件的某个方法，快速完成某些能力，是一种在actions中直接使用组件的方法。