不！我是一个主要在Postgres/NodeJS/Apollo GraphQL/React堆栈中构建应用程序的小团队的后端部分。
在我的爱好项目中，我使用golang，并且在用Cobra/Viper构建CLI应用程序方面已经很熟练了。我开始考虑将所有关键的业务逻辑和数据访问转移到可重用的小型CLI应用程序中，这些应用程序构建在golang中，并作为二进制文件分发。我设想这些CLIIs的输出将产生机器可读的json。
然后，nodejs graphql服务器将成为CLI二进制文件的更浅的包装器，并使用类似const{stdout，stderr}=await exec('<<my CLI--here>')/code>的内容进行调用
将业务逻辑和数据访问分离到CLI中，对于在非服务器场景中的可重用性来说，这对我很有吸引力。而且我只是真的很喜欢在go中写而不是在Node中写。这似乎是个不错的主意，但也许我忽略了这种方法的一些陷阱？有人采取过这样的方法吗？
仅当个别用户从终端使用它们时才使用实用工具。从nodejs服务器启动如此多的cli进程，在nodejs服务器获得过多并发请求的情况下，效率和可伸缩性都不高，启动过多的cli进程会使其速度变慢并消耗系统资源。
我会使用API。节点服务器将把请求通过管道传送到go api服务器。现在关于cli，要在独立模式下由用户从终端使用，您需要将所有逻辑添加到一个单独的模块中。这个模块库可以托管（或使用）到Go api服务器和CMD中。cmd实用程序和go http api服务器进程将只是主机，而实际的东西在模块中。
