基于 Effect 的后端 api 设计

[llej]

#最近在开发 TsFullStack ,其中的后端 api 深度集成了 Effect 。

为什么是 effect-ts

例如下面这个上传接口，他内部是依赖了 authService （用户信息），如果我们通过参数来传递 auth 的话，在嵌套调用的情况下会非常繁琐，尤其是后期新增一个依赖，那么就要全链路改动。

为了避免上面这个问题一般采用线程变量（在 node 中可以使用 CLS）或者 InversifyJS 这样的方案，又或者在 vue 中也有 provied inject 这样的方案。

但他们有一个最大的缺点就是在实际运行程序（或者通读代码）之前没法知道一段程序究竟依赖了什么，而 Effect 通过巧妙的 ts type 解决了这个问题，例如下面是 TsFullStack 中运行包含上面 upload 相关接口的程序，我手动注释掉了 provide authService 的代码，可以看到 ts 就会提示缺少了 AuthService 。

这就实现了在实际运行程序之前知道一段程序究竟依赖了什么

那么什么场景非常需要这个特性呢？

1. 编写严谨不易出错的程序
2. 编写单元测试，没有这个特性的话编写单元测试就需要开发者反复阅读代码确定一个片段依赖了什么。

[lmshl]

我真的觉得在 TS 里搞 AE 很难被大众认可甚至采用。

大佬有这些精力，为何不试试去 Kotlin ，Scala ，Rust 社区发展？
Kotlin 有 context parameters （从 context receivers 进化而来）
Scala 支持 Tagless final ，Rust 的 trait 系统一样可以模拟。
这几个都是 first-class 语法级别的支持，还不用在 TS 里自造 DSL 。
我觉得在 Rust/Kotlin 里推广一下 AE 应该比 TS 社区里推广更容易吧。

[dragondove]

严谨不易出错只要类型系统够强都能做到，不需要引入 effect 。依赖注入个人认为 spring 的这一套依然是最易用的，缺陷是编译器无法知道依赖是否存在，但是问题不算太大，只要你的组件不是惰性的，启动时也会报错，不会在提供服务时出错。（ spring 这套在有宏的语言里可以做到编译期生成从而确保依赖存在）。单元测试对于结构类型的语言应该很容易实现替换，对于 jvm 上的则因为 jvm 强大的动态代理很容易实现。对于编译期功能强大的语言也有编译期处理的方案。
Scala 3 现在主推的是 direct style programming ，直接简单的，普通开发者能理解的。可以说会 java ，就会用 direct style scala 。而 scala 2 时代社区基本都是 effect system ，门槛太高了，收益不明显。（当然 jvm 上也受到虚拟线程发布的影响，虚拟线程这个抽象方案让结构化并发变得很简单，异步代码可以很容易被集成到同步代码中而没有明显的性能影响，虽然极限性能还是比不过全异步生态或者 effect runtime ）

[parad]

看来来有点像 Ramda https://ramdajs.com/

[llej]

@lmshl 我更喜欢 ts ，最重要的就是可以前后端同构

[llej]

@dragondove effect 还有一个优势就是可以知道会抛出哪些错误