O.! I'm the backend half of a small team that primarily builds apps in postgres/nodejs/apollo graphql/react stack.
In my hobby projects I use golang and have gotten decent at constructing CLI apps with cobra/viper. I'm starting to play with the idea of moving all the critical business logic and data access into reusable small CLI apps built in golang and distributed as binaries. I envision the output of these cli's to produce json as to be machine readable.
The nodejs graphql servers would then become more shallow wrappers around the CLI binaries and called using something like const { stdout, stderr } = await exec('<<MY CLI --here >>');
Separating out business logic and data access into a CLI is attractive to me for reusability in non server scenarios. Also I just really like writing in go more than node. This seems like a decent idea, but perhaps I am overlooking some pitfall to this approach? Anyone taken an approach like this?
Use utility only when individual users use them from terminal. Launching so many cli processes from nodejs servers would not be efficient and scalable in case the node server gets too many concurrent requests.Launching too many cli processes would make it slow and consume system resources.
I would use an API. The node server would pipe the request to the go api server. Now about cli, to be used in standalone mode from terminal by a user, you need to add all your logic into a separate module (lib). This module lib can be hosted (or used) into Go api server as well as cmd. The cmd utility and go http api server processes would just be host while actual thing in module.
Or even better the command-line utility will have 2 modes to run as http server or as standalone utility.