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

学习Golang要努力，但是不要急！今天的这篇文章《将数据访问和业务逻辑移至 CLI 并在 graphql 服务器中使用》将会介绍到等等知识点，如果你想深入学习Golang，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

哦！我是一个小团队的后端，主要在 postgres/nodejs/apollo graphql/react 堆栈中构建应用程序。

在我的业余爱好项目中，我使用 golang，并且在使用 cobra/viper 构建 CLI 应用程序方面表现得相当不错。我开始考虑将所有关键业务逻辑和数据访问转移到用 golang 构建并作为二进制文件分发的可重用小型 CLI 应用程序中。我设想这些 cli 的输出会生成机器可读的 json。

然后，nodejs graphql 服务器将成为 CLI 二进制文件周围更浅的包装器，并使用类似 const { stdout, stderr } = wait exec('<>'); 之类的内容进行调用

将业务逻辑和数据访问分离到 CLI 中对于非服务器场景中的可重用性很有吸引力。而且我真的很喜欢用 Go 语言编写而不是 Node.js 语言。这似乎是一个不错的主意，但也许我忽略了这种方法的一些陷阱？有人采取过这样的方法吗？

解决方案

仅当个人用户从终端使用实用程序时才使用实用程序。 如果节点服务器收到太多并发请求，从 Nodejs 服务器启动如此多的 cli 进程将无法高效且可扩展。启动太多 cli 进程会使其变慢并消耗系统资源。

我会使用 API。节点服务器将请求传送到 go api 服务器。现在关于 cli，要由用户从终端以独立模式使用，您需要将所有逻辑添加到单独的模块 (lib) 中。该模块库可以托管（或使用）到 Go api 服务器以及 cmd 中。 cmd 实用程序和 go http api 服务器进程将只是主机，而实际的东西在模块中。

或者更好的是，命令行实用程序将有 2 种模式作为 http 服务器或独立实用程序运行。

终于介绍完啦！小伙伴们，这篇关于《将数据访问和业务逻辑移至 CLI 并在 graphql 服务器中使用》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！