Setup & Tooling
Gopher says
Welcome to Baton Junction! I’m Gopher, and I’ll be your guide as you learn Go by building a C1 Baton connector. First stop: getting your tools set up.
In baton-junction, we sync users, groups, and roles from a REST API using the C1 Baton SDK. Everything you learn here applies directly to building connectors.
Installing Go
Download Go from go.dev/dl and follow the installer for your OS. Verify it works:
go versionYou should see something like go version go1.25.2 darwin/arm64. The exact version and platform will vary.
The Module File
Every Go project starts with a go.mod file. It declares the project’s identity and its dependencies - similar to Python’s pyproject.toml or Node’s package.json.
When you start a new Go project, you initialize the project (which creates the module file) with go mod init:
go mod init example/baton-junctionThe command writes the first version of go.mod for your project. In
baton-junction, it establishes the module path and the minimum Go version:
Here’s the baton-junction module file, stripped to its essentials:
module example/baton-junction
go 1.25.2 The module path is how other Go code refers to this project. In baton connectors, this is a GitHub URL like github.com/conductorone/baton-okta.
Project Structure
Go projects follow a conventional layout. Here’s how baton-junction is organized:
baton-junction/
cmd/baton-junction/main.go the executable
pkg/
client/ HTTP client, API calls, models
config/ CLI configuration
connector/ core connector logic
go.mod module definition
go.sum dependency checksums cmd/ contains entry points. Each subdirectory compiles to a separate binary. pkg/ contains library code, grouped by responsibility.
Quick Quiz
Time to test what you’ve learned. Type the Go command that answers each question.
What command creates a new go.mod file for a project?
What command runs all tests in a project recursively?
What command compiles your project into a binary?
Before Go modules (pre-2019), all Go code lived in a single workspace directory
called GOPATH. Every project, every dependency, every binary - all crammed
into one tree. You couldn’t have two versions of the same library, and
your project’s location on disk determined its import path.
go.mod replaced all of that. Each project is self-contained with its own
dependency list and version pins. You can put your project anywhere on disk,
and go mod tidy keeps everything in sync. If you see old tutorials
mentioning GOPATH, you can safely ignore them.
Gopher says
Your tools are ready and your project is structured. You know how go.mod
defines a module, how cmd/ and pkg/ organize code, and where everything
lives in a Baton connector.
In baton-junction, this layout is the same one used across baton connectors in the C1 ecosystem. Once you know where things go, you can navigate any connector.
Next: types and variables!
Next Lesson
Types & Variables