云函数开发 - 前后端协作

protobuf是google发明的一种用以序列化结构化数据且语言无关/平台无关的可扩展机制。下文均一pb简称之。

团队的后端开发语言是Go,pb是前后协作/后端之间协作的桥梁。在以往的开发实践中,上游的调用者通常是查阅下游提供的pb文档,了解对应的结构并针对相关的字段含义编写逻辑代码。开发者需要在代码和pb文档间频繁切换,避免出现包含但不限于下列失误

  • 使用错误的字段
  • 使用错误的字段类型

以一个示例的pb文档为例

syntax = "proto3";
package test;

message DemoResponse {
  // 当前时间戳
  string timestamp = 1;
  // 请求者的父亲的年龄
  int32 fatherAge = 2;
  // 请求者的儿子的年龄
  int32 sonAge = 3;
}

撇开字段命名和类型使用的合理性(ps. 有些情况下对于已有的协议格式我们也只能践行拿来主义),对于上面的pb文档,如果不对着文档编写代码,极有可能踩的坑就是

  • timestamp按数值类型操作
  • fatherAgesonAge的业务语义搞混

对接一个接口尚且如此,可以想象当云函数作为聚合层要对接多达10个甚至更多的接口场景,基本成了开发者社死现场直播。

回过头重新审视问题,其本质在于文档到代码的转化需要大量的切换,如果pb文档可以直接转成代码,问题是不是能解决呢?

答案如你所料,是肯定的

开发语言无关是pb的特性之一,而pb是通过compiler实现多语言支持。同样的,通过compiler和插件,pb可以转成ts代码。相应的协作流程就可以优化为

1. pbts

得益于pb官方提供的compiler和社区的插件,安装compiler和相应的插件包即可

  • 安装compiler
npm i protoc3 --save-dev

因为pb的compiler都是使用官方提供的可执行文件,因此并不能直接安装使用。社区有个包protoc,其本质是将github上指定版本的compiler可执行文件下载到本地,然后通过nodejs的excuteFile方法启动文件执行。

笔者在使用protoc时,经常出现从github下载包的过程失败导致安装不成功。于是将protoc包的文件下载和搜索本地可执行文件进行相关改造,将远端较新的可执行文件内置到npm包中,优化压缩文件解压逻辑。为表示对原作者的敬意,取名protoc3。

  • 安装插件
npm i ts-proto --save-dev
  • 操作系统兼容

windows操作系统和非windows操作系统对于可行文件的运行机制是不同的,不仅可运行文件的格式不同,对文件路径中的间隔符要求也不同。针对这些差异,笔者将相应的sh执行区别为2份,通过统一的入口js文件,通过系统判断,分别执行,相应的脚本如下

  • 非windows操作系统的sh脚本
# Path to this plugin
PROTOC_GEN_TS_PATH="./node_modules/.bin/protoc-gen-ts_proto"
PROTOC_PATH="./node_modules/protoc3/protoc/bin/protoc"

# Directory to write generated code to (.js and .d.ts files)
OUT_DIR="./src/_types"

${PROTOC_PATH} \
    --plugin="${PROTOC_GEN_TS_PATH}" \
    --ts_proto_out="${OUT_DIR}" \
    --ts_proto_opt=outputEncodeMethods=false,outputJsonMethods=false,outputClientImpl=false \
    ./protos/*.proto
  • windows操作系统的sh脚本
# Path to this plugin
PROTOC_GEN_TS_PATH="protoc-gen-ts_proto=.\node_modules\.bin\protoc-gen-ts_proto.cmd"
PROTOC_PATH=".\node_modules\@wesure\protoc\protoc\bin\protoc.exe"

# Directory to write generated code to (.js and .d.ts files)
OUT_DIR="./src/_types"

${PROTOC_PATH} \
    --plugin="${PROTOC_GEN_TS_PATH}" \
    --ts_proto_out="${OUT_DIR}" \
    --ts_proto_opt=outputEncodeMethods=false,outputJsonMethods=false,outputClientImpl=false \
    ./protos/*.proto
  • 统一的入口执行文件
const spawn = require('cross-spawn');
const chalk = require('chalk');

const isWindows = process.platform.indexOf('win') === 0;
spawn.sync('sh', [isWindows ? './scripts/pb2ts_windows.sh' : './scripts/pb2ts.sh']);
  • 将命令注册到npm scripts
"scripts": {
    "pb2ts": "node ./scripts/pb2ts.js"
  }
  • 运行命令 npm run pb2ts

以本文前面给出的pb示例为例,转换后对应的ts代码如下

export const protobufPackage = "test";
export interface DemoResponse {
  /** 当前时间戳 */
  timestamp: string;
  /** 请求者的父亲的年龄 */
  fatherAge: number;
  /** 请求者的儿子的年龄 */
  sonAge: number;
}
2.引入转换后的ts
import { DemoResponse } from './_types/protos/test';
3.智能提示
image.png

pb转换为ts的能力内置到项目中,基于pb文档的协作其本质变成代码间的引入,转换后的ts代码不仅可以直接用于开发,同时在pb文档上的丰富注释也可以完整保留,开发者只需要在自己的ide中尽情地享受代码编写的畅快。

还在等什么呢?抓紧试试吧!

你可能感兴趣的:(云函数开发 - 前后端协作)