This is more for my notes, a list of resources and perhaps a little discussion on the side.
Here is some ‘official’ documentation about name of the package. The short version is that the
main function needs to be in the
package main. Package name does not need to be unique, but the full import path does.
Some package naming conventions can be found here.
This says that it’s talking about package organisation but it covers naming of packages, and the effect name and location has on packages. Short version; lower case, don’t bother repeating package names in package types. But it’s worth reading all of this post along with anything else that Dave Cheney writes.
There are 3 interesting things to read about laying down your packages:
These 2 pages are interesting background to what kind of code to put in which packages. Short version:
- Put executatble commands (ie. with your
mainfunction) in sub-packages under
- Don’t forget to put your imported Go packages under
vendor. This is the recommended idiomatic way of managing dependencies and is the subject a lot of discussion on the interwebs
examplesfor code examples to tell people how to use your code
There are plenty of other little gems but that’s the crux of it.
My favourite result from my rabid googling is this. Here we have 5 concrete rules with good reasoning around it. For me, the important take-aways are:
- The root package should contain domain objects and interfaces for services
- Organise sub-packages by dependency, including to packages such as
Again, there is the recommendation that you’re
main packages sit in their own sub-package under
cmd. This time though, it’s suggested that this is where you want to do your dependency injection.
One thing that this article doesn’t cover is where the business logic sits. The examples on the page have this spread out between a
postgres sub-package and the root package. My gut feel is that there needs to be a certain amount of interpretation about what needs to go in to your dependency related sub packages and the root package.
Buffalo happens to be my favourite Go project at the moment (as you might have observed when I introduced Gostars). The thing is, Buffalo doesn’t go anyway near this organisation. Domain models sit under
models, handlers and business logic sits under
app. In there too are directories for putting HTML templates and static assets.
This layout could be because of the Ruby On Rail heritage of this library. A side effect of this though is that you will hit several of the problems that were discuss in articles above. Beware but bare in mind that Buffalo offers an incredibly powerful approach to writing your web app.
Goa is a different web framework. Again, it follows its own organisation.
app contains handlers and request and response objects,
controllers contains the actual controllers with business logic.
This appears to follow the example of the Gihub project above.