The /internal directory stores non-exported (“private“) application and package code that, in comparison to code in the /pkg directory, can never be imported in other modules. As of Go version 1.4 the compiler itself enforces the internal directory naming pattern and prevents all packages within this directory to be imported by other modules outside the module in which they reside. Note that this pattern it not limited to the top level /internal directory but to any nested internal directory within the module.
A common practice is that the /internal directory contains sub-directories to separate code targeted only for individual applications using the same pattern like the /apps directory or module-wide code like stored in the /pkg directory.
Each application is placed in an individual directory that should match the name of the resulting binary executable.
The structure always depends on the type and use case(s) of the application, but in general the code only consists of the main package and function that mainly imports and invokes reuseable code from the /internal and directories. This helps to better visualize the intended package use and distinguish shared and non-shared code.
Given the example of the /api directory the structure could be created as follows:
internal
├─ apps
│ ├─ notes
│ └─ notes-sync
└─ pkg
├─ platform
│ ├─ http
│ ├─ logging
│ ├─ messaging
│ └─ transport
├─ product
│ └─ store
└─ support
├─ data
└─ project
Next to the experience with own projects and golang-standards/project-layout, many other large, production-grade and well-known projects of the Go ecosystem have been used as references: