Stellar's public monorepo of go code
Go Logos Other
Latest commit 03b008f Jan 9, 2017 @nullstyle nullstyle committed on GitHub Merge pull request #27 from stellar/replace-placeholders
support/db: Fix unescaped placeholders in sql queries
Failed to load latest commit information.
.vscode Add remote debugging config Aug 10, 2016
address Rename internal to support, so the private repo can access the common… Aug 24, 2016
amount Initial import from go-stellar-base Aug 4, 2016
build build: Delint and refactoring Oct 3, 2016
clients clients/stellartoml: fixes failing example Dec 7, 2016
crc16 Initial import from go-stellar-base Aug 4, 2016
docs/reference Add beginnings of developer portal docs Sep 13, 2016
examples Fix busted tests Sep 13, 2016
exp Add some docs Aug 19, 2016
handlers/federation support/db/dbtest: integration test assertions Sep 28, 2016
hash Initial import from go-stellar-base Aug 4, 2016
keypair Initial import from go-stellar-base Aug 4, 2016
meta Finish import of go-stellar-base, add beginnings of readme Aug 4, 2016
network build: Remove default network setting Oct 3, 2016
price Work on some documentation Sep 1, 2016
services Rename url to dsn Dec 13, 2016
strkey Rename internal to support, so the private repo can access the common… Aug 24, 2016
support support/db: add "ReplacePlaceholders" Jan 9, 2017
tools Add simple transaction summary Aug 19, 2016
xdr Docs fixes Aug 19, 2016
.gitignore Import stellar-archivist Aug 17, 2016
.travis.yml Package applications using go 1.7 Sep 29, 2016 Update changelog Oct 3, 2016 Adds some more supporting docs Aug 17, 2016
COPYING Add license notice, imported from stellar/archivist Aug 8, 2016
Gemfile Initial import from go-stellar-base Aug 4, 2016
Gemfile.lock Initial import from go-stellar-base Aug 4, 2016
LICENSE-APACHE.txt Add license notice, imported from stellar/archivist Aug 8, 2016 Update govalidator to custom fork Nov 11, 2016
Rakefile Initial import from go-stellar-base Aug 4, 2016
doc.go Update README Aug 17, 2016
glide.lock Update govalidator to custom fork Nov 11, 2016
glide.yaml Update govalidator to custom fork Nov 11, 2016
main_test.go Fix import in example Aug 22, 2016

Stellar Go

Build Status GoDoc Go Report Card

This repo is the home for all of the public go code produced by SDF. In addition to various tools and services, this repository is the SDK from which you may develop your own applications that integrate with the stellar network.


NOTE: this repo presently uses a fork of govalidator that incorporates Vendored dependencies must be restored (using glide install) to get proper behaviour. In other words, this repo is not currently "go gettable"

This repository depends upon a number of external dependencies, and we use Glide to manage them. Glide is used to populate the vendor directory, ensuring that builds are reproducible even as upstream dependencies are changed. Please see the Glide website for installation instructions.

When creating this project, we had to decide whether or not we committed our external dependencies to the repo. We decided that we would not, by default, do so. This lets us avoid the diff churn associated with updating dependencies while allowing an acceptable path to get reproducible builds. To do so, simply install glide and run glide install in your checkout of the code. We realize this is a judgement call; Please feel free to open an issue if you would like to make a case that we change this policy.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

  • clients contains packages that provide client packages to the various Stellar services.
  • exp contains experimental packages. Use at your own risk.
  • handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the Stellar protocol into your own http server.
  • support contains packages that are not intended for consumption outside of Stellar's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
  • support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
  • services contains packages that compile to applications that are long-running processes (such as API servers).
  • tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the Stellar network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

  • main.go: Every package should have a main.go file. This file contains the package documentation (unless a separate doc.go file is used), all of the exported vars, consts, types and funcs for the package.
  • internal.go: This file should contain unexported vars, consts, types, and funcs. Conceptually, it should be considered the private counterpart to the main.go file of a package
  • errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
  • example_test.go: This file should contains example tests, as described at

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Coding conventions

  • Always document exported package elements: vars, consts, funcs, types, etc.
  • Tests are better than no tests.