Go: repository layout for microservices with shared code

We recently started using Go for new microservices. Each microservice is a Go module, and we manage them as a monorepo:

/
  services/
    s1/
      go.mod
      main.go
    s2/
      go.mod
      main.go

This works fine, but now we need to share some code between s1 and s2 - some structs used by both services, a function that uploads to S3, etc.

What's the correct way of managing this situation? Ideally, I'd have a common directory at the repo root (sibling of services) and put the common code there - but how will Go take the code from there when compiling s1 and s2?

I think what you're asking is really just a variation of "<https://stackoverflow.com/questions/50904560/how-to-structure-go-application-to-produce-multiple-binaries>".

You would move your go.mod to the top-level directory rename, so that you have this layout:

.
├── common
│   └── common.go
├── go.mod
└── services
    ├── s1
    │   └── main.go
    └── s2
        └── main.go

And a go.mod that starts with something like:

module mymodule

If common/common.go looks like this:

package common
func CommonFunction() string {
	return "This is a common function"
}

Then in services/s1/main.go, you can import the common module:

package main
import (
        "mymodule/common"
        "fmt"
)
func main() {
        res := common.CommonFunction()
        fmt.Println(res)
}

And you would build the s1 service like this:

go build ./services/s1

Building s2 would be similar:

go build ./services/s2

You would typically have a top-level Makefile to automate building of the multiple services.