[feature request] 服务端在其它语言中的实现

[shynome]

看了文档，感觉和thrift协议很像，特色在于使用了前端友好、有类型检查的typescript进行接口定义，既然这么想所以我在想有没有可能出个其它语言(大火的go)的服务端实现彻底干翻thrift这种自定义dsl的协议

[shynome]

可以把参数的解析验证使用 assemblyscript 重写，方便编译成 wasm 在其他语言中使用

[k8w]

哈喽，感谢关注~

有没有可能出个其它语言(大火的go)的服务端实现彻底干翻thrift这种自定义dsl的协议

主要是其它语言的类型系统要大幅弱于 TypeScript，例如没有 Union Type、Intersection Type 等高级特性。 如果要兼容其它语言，意味着要在类型系统上做牺牲，只能使用基础、通用的类型。 如果是这样，那么 gRPC 其实已经足够满足需要了，它是跨语言跨端，并且也支持 TypeScript 的。 而 TSRPC 的主要特点就在于它是面向 TypeScript 的高级类型特性的。（这对于 Web 应用场景非常实用）

可以把参数的解析验证使用 assemblyscript 重写，方便编译成 wasm 在其他语言中使用

这对于跨语言支持确实是一个很不错的方式~~

总结

总得来说，TS 类型系统的跨语言支持是一个炒鸡大的工程量，但如果收益只是将 gRPC 的类型定义从 protobuf 改为了 TypeScript，就显得不太划算。 全栈使用 TypeScript，还有跨端共享复用代码的额外收益，除非特别性能敏感的场景，这些优势很难被其它语言所替代。

[shynome]

我觉得不会在类型系统上作出牺牲, 因为类型系统是存在于定义协议的文件中, 而验证则是在生成的验证文件中, 生成的验证文件里并不存在类型系统, 验证文件是将要编译成 wasm 的 assemblyscript 文件, 相当于只是输出验证器, 至于其他语言的服务端可由其他语言的开发者实现

当然过于理想化了

[k8w]

@shynome 了解，你的意思是说在其它语言里仅仅利用运行时刻的验证器，在代码层面只是使用类似 JSON 这样的通用格式。 是个不错的办法，我研究看看 AssemblyScript，理论上可行~

它们已经被抽成了独立的模块，有兴趣也可以了解看看： 验证器：https://github.com/k8w/tsbuffer-validator 编解码器：https://github.com/k8w/tsbuffer 协议生成器 http://github.com/k8w/tsbuffer-proto-generator

[shynome]

AssemblyScript 目前还是个坑, 不妨再等几年再开始

独立模块的话, 有空了的话我试着实现下(可能半年后