将数据访问和业务逻辑移动到 CLI 并在 graphql 服务器中使用

Question

断续器我是一个小团队的后端，主要在postgres/nodejs/apollo graphql/react stack中构建应用程序。

在我的爱好项目中，我使用golang，并且在使用眼镜蛇/蝰蛇构建CLI应用程序方面表现出色。我开始考虑将所有关键业务逻辑和数据访问移动到可重用的小型CLI应用程序中，这些应用程序内置于golang中并作为二进制文件分发。我设想这些cli的输出来生成json，这是机器可读的。

然后，nodejs graphql 服务器将成为 CLI 二进制文件的更浅的包装器，并使用类似 const { stdout, stderr } = await exec('<<MY CLI --here >>');

将业务逻辑和数据访问分离到 CLI 中对于我在非服务器方案中的可重用性很有吸引力。另外，我真的很喜欢写在go中而不是node。这似乎是一个不错的主意，但也许我忽略了这种方法的一些陷阱？有人采取这样的方法吗？

Answer 1

仅当个人用户从终端使用它们时才使用实用程序。如果节点服务器获得过多的并发请求，从 nodejs 服务器启动如此多的 cli 进程将不是高效且可扩展的。启动过多的 cli 进程会使其变慢并消耗系统资源。我会使用API。节点服务器将请求通过管道传输到 go api 服务器。现在关于 cli，要由用户从终端以独立模式使用，您需要将所有逻辑添加到单独的模块 （lib） 中。这个模块库可以托管（或使用）到Go api服务器以及cmd中。cmd实用程序和go http api服务器进程将只是主机，而模块中的实际内容。或者更好的是，命令行实用程序将有2种模式作为http服务器或独立实用程序运行。