Template for Golang services

• Quick start
• Project structure
• Tools

Local development:

# Install dependencies
$ make install

# Run app with migrations
$ make run

├── assets
│   └── credentials
├── cmd
│   └── app
├── configs
├── constants
├── githooks
├── internal
│   ├── app
│   ├── controller
│   ├── middleware
│   ├── [any domain]
│   │   ├── dto
│   │   ├── model
│   │   ├── module
│   │   ├── repo
│   │   └── service
│   ├── router
│   └── server
├── migrations
├── pkg
│   ├── databases
│   ├── failure
│   ├── logger
│   └── pubsub
├── scripts
│   └── bash
└── ...

Static files to go along with the repository.

Configuration and logger initialization. Then the main function "continues" in internal/app/app.go.

The config structure is in the configs.go. First, default values of non-sensitive configuration are pre-defined within default.go.

We choose the Viper library for reading config from config.yaml. The environment variables are loaded if their tag match, then overwrite the default value.

Immutable values during the application's execution

Git hooks

There is always one Run function in the app.go file, which "continues" the main function.

This is where all the main objects are created. Dependency injection occurs through the "New ..." constructors. This makes the business logic independent from other layers.

Server handler layer for REST HTTP server Gin framework.

Inspects and filters HTTP requests entering the application.

Server routers are written in the same style:

• Handlers are grouped by area of application (by a common basis)
• For each group, its own router structure is created, the methods of which process paths
• The structure of the business logic is injected into the router structure, which will be called by the handlers

Start the server and wait for signals for graceful completion.

Demonstrating a sample of how to implement Domain Driven Design in Go. Each package consists of:

• dto
• model: model of business logic can be used in any layer. There can also be internal methods of their own (e.g. validation).
• module: encapsulation of a domain's dependencies.
• repo: an abstract storage (database) that business logic works with. Under the hood, use GORM for query and data manipulation.
• service: consists of business logic of the application.

Contains SQL scripts used for database migration.

Initiate connections to all the kinds of databases.

Wrapper and transalator of application's errors.

We custom and utilize zap as our primary logger.

Scripts to perform various build, install, analysis, etc. operations.

These scripts keep the root level Makefile small and simple.

We use golanglint-ci to enforce a consistent code style across our codebase. Place .golanglint-ci.yml at the root folder and follow the instruction to integrate your editor.