design patterns - Structuring go project for this use case

Question

Closed. This question is opinion-based. It is not currently accepting answers. question from:https://stackoverflow.com/questions/65842069/structuring-go-project-for-this-use-case

Answer 1

In addition to what @Muhamed Keta writes, I would add the suggestion of using sub-packages for each of the providers instead of one mega-package with 10s of providers in it. This would look like this:

/cmd/app
/config
...
/lib # or /utils 
/providers
    /provider1
        dtos.go
        client.go
        ...
    /provider2
        dtos.go
        client.go
        ...

In go, the package name becomes a namespace and a non-optional identifier/discriminator for client code to use. In this way you avoid having to write longer, redundant and sometimes stuttering names to differentiate from provider to provider:

So in code using your providers instead of writing providers.Provider1Client you'd have provider1.Client. This seems to be a common go pattern/best practice.

This also means that all code that relates closely to the implementation of each provider lives in close proximity, preventing name collisions and aiding developers that focus on a provider exclusively.

I've added a lib (or alternatively utils) package that would contain generic code that may be shared among many providers.

This is subjective, but hopefully I've outlined some reasonable pros given the language's constraints.