felixin

比如怎么做定制 logging，继承官方那个简陋的 Logger 自己写实现，然后发现 logger 的注入不推荐用 constructor 注入，而是要使用成员变量初始化，并且在 app module 之外的 logger 和依赖注入管理的 logger 是不同的初始化方式——和 java 或.net 之类的对比一下;

比如要上 graphql，dataloader 怎么使用文档没提，最后是根据网上的代码改了一个自己做的装饰器，用 ModuleRef 在 context 里动态写入属性;

怎么和数据库交互，typeorm 是个 leaky abstraction，join 的写法比直接写 sql 还复杂，而且也不能覆盖数据库原有的特性，比如写不了 cte 。pg 的 view 只支持写一次不支持更新，最后研究了 typeorm 的源码在每次启动的时候得把旧的 view 删了再重新创建 view;怎么做 transaction，用 query runner 对象显式执行 sql，如果这个 transaction 横跨多个 service，要把这个 query runner 一路传递出去，看看 nestjs 的文档那一节，再和 ef core 之类的对比看看;想要做 @Transactional 注解，需要深入研究 cls-hooked，一不小心就内存泄漏;

换了一个 slonik，类型标注是用 flow 写的（最近改成 ts 了），用稍微复杂点的数据结构就需要处理 type parser 问题; transaction 的写法一样要用 cls-hooked 自己封装，否则 service 调用 service 就是两个不同的 transaction;

mode_modules 依赖稍微多点，打包 docker 直接 1~2G，还经常爆出被依赖投毒，yarn2 的 berry 搞了快两年还是一堆兼容性问题，基本无法实用。

最重要的是 typescript 本身的问题，毕竟它只是 js+type，不是真静态类型语言，改变不了 js 动态的本质，有时候看着 type 都没问题跑起来一样 type error，重构改名都要担心哪里会 break; 从 ror 换成 nodejs 换汤不换药，ror 解决不了的问题 nodejs 一样无能为力。

还有很多和业务强相关的就不说了，一路上大小坑要么网上只有几个人遇到同样的问题然后 publish 一些 dirty 方案，要么在官方 issue 上挂了一两年的没有解决最后被 close 。确实这些问题不是不能自己动手解决，只不过我们精力没必要放在它们上面。

nestjs 想做 nodejs 上的 aspnetcore/spring，那为什么不直接用他们呢，这两者已经做到极致了。我们的看法 nodejs 只适合做 view 层，比如 SSR 就很合适，但不适合处理深层次的业务逻辑。当然团队水平不同，业务能力不同，看法不一样，方案也不一样，我们是小团队，也许适合别人不适合我们。