You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
a server -- postgres driver, SAML, OpenTelemetry
client library to interact with the APIs -- (none)
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.
The text was updated successfully, but these errors were encountered:
@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.
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:
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.
The text was updated successfully, but these errors were encountered: