I’m researching whether I should follow a standard directory structure for my new open source application. I want to do this in order to allow people to easily understand the code and to easily contribute.
It’s a medium-sized web app, which consists of a JSON API backend written in Go, together with a Next.js frontend written in Typescript.
According to Go Project Structure Best Practices, the most common options are:
- For small apps: flat structure. Putting all source files in the toplevel.
- For medium/large apps: splitting files into semantic groups. Each group directory is located in the toplevel.
- For large or “older” apps: the “traditional” structure, I think it’s referring to go-standards/project-layout. The toplevel consists of subdirectories by technical group (“pkg” for publicly-consumable sources, “internal” for only internally-consumable sources) as opposed to by semantical group. Within the pkg or internal subdirectory, one can still have semantical groups.
Question 1: Which one should I pick for my medium-sized app? Does the Go community have widespread agreement on which option to go for?
A friend is a big advocate of go-standards/project-layout. According to him, this is the Go standard, and allows every Go developers to immediately get started and easily understand the structure.
Question 2: Is it true that go-standards/project-layout is the golden standard with widespread acceptance?
When I look at actual Go repositories, I don’t actually see this as the most accepted layout. For example Hugo, HashiCorp Vault and Terraform all seem to use layout #2. Outside Kubernetes, I have a hard time finding go-standards/project-layout. Have I missed something?
Question 3: Go Project Structure Best Practices says that layout #3 is for “older” apps, and that s/he expects that the Go community will gradually drop this layout as Go modules start becoming more prevalent. What is your opinion on this?