Add API client library / cli app?

[tko]

This is an issue that came up in our own internal (private, sorry) app for which I've not found a good sample (though not having much time / priority to research.)

Let's say we want to have a service providing the following. Including some imaginary dependencies that are unique to each:

1. a server -- postgres driver, SAML, OpenTelemetry
2. client library to interact with the APIs -- (none)
3. CLI client to interact with the APIs -- terminal colors

In its current form everything is in a single module and so any dependencies needed anywhere will become (indirect) dependencies to the clients, and if you're running security checks over your dependencies you can get flagged that your API client (which is not much more than a glorified http client) has a potential vulnerability due to a database driver/SAML/OpenTelemetry/LLMs -- any other library really -- which are implementation details of the server only and shouldn't really even be visible to the (http) clients.

I believe properly hiding the implementation details would require at least two, maybe three modules with different dependencies sets which isn't entirely trivial to set up (and harder to refactor into afterwards) and a blueprint would be helpful.

[bnkamalesh]

@tko thanks a lot for the suggestion and I agree, it would be better to have nested Go modules to avoid unnecessary dependencies being downloaded when using lib. I have been planning a major refactor, and would include your suggestion as part of it.

#5 this is still in draft + in progress, would merge once it's polished enough.

[bnkamalesh]

@tko the PR is merged, but finally decided to not create nested Go modules. In case of Go imports, it does not import all the dependencies of the parent module, rather only the respective imported package's dependencies. Considering the issue you listed is related to 3rd party tools' implementation, I thought it was best to not complicate the app structure by introducing nested modules.