bnkamalesh / goapp Goto Github PK

First of all thanks @bnkamalesh for the excellent repo. We looked at many golang web boilerplates and this was the best we found!
Since in real world we will have many domains, wont the number of args to api.NewService become very large? What is a clean way to manage this?

For eg:

type API struct {
	logger        logger.Logger
	users         *users.Users
	notes         *notes.Notes
	blogs         *blogs.Blogs
	subscriptions *subs.Subscriptions
	// ...
}

and the corresponding NewService like this:

// NewService returns a new instance of API with all the dependencies initialized
func NewService(l logger.Logger, us *users.Users, ns *notes.Notes, bs *blogs.Blogs, ss *subs.Subscriptions) (*API, error) {
	return &API{
		logger: l,
		users:  us,
	}, nil
}

Hi Kamaleshwar,

First of all big thanks the great work you have put here. For someone just starting with go and with the amount of suggestions there I liked the level of details here and the explanation and I find That all make sense to me. That will be awesome to see how you do integration tests also and what do you think about the necessity (or not) of unit-testing (vs interface pollution).

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.