Boilerplate of the GoLang project with microservices architecture

3 min readApr 16, 2020

Read more about the boilerplate on the GitHub repository https://github.com/begmaroman/go-micro-boilerplate

NOTE 1: If something is not fully clear, feel free to create an issue in GitHub or add a comment here. Let’s create an excellent boilerplate together!

I’ve created the example of the GoLang project based on the microservices architecture. This is a simple project that provides CRUD operations related to the user entity.

There are two microservices, one web service that exposes REST API, and the second one is the RPC microservice that implements functionality to work with users. Once a user sends an HTTP request to the web service, it handles the incoming request, prepares data and calls the RPC service through RPC request.

Technologies

Go Micro framework provides the core requirements for distributed systems development including RPC and Event-driven communication. Read more about this framework on their official GitHub page.

NATS is used as a discovery service, message broker service, and transport.

All services are dockerized and can be adjusted by docker-compose configuration. Check Dockerfiles and docker-compose.yaml file in the root of the project.

Use Go modules to manage the dependencies of the project.

Structure of services

This section describes and explains the architecture of microservices both web and RPC.

There are two microservices in this project:

rest-api-svc is the web service that exposes REST API endpoints. It allows users to do something with the data, e.g. user entity.
account-svc is the RPC microservice that provides some business logic related to users. It exposes the API to do CRUD operations.

RPC service:

There are 3 layers:

The transport layer represents the API of the service. It can be implemented using HTTP, RPC, WS, etc. This layer prepares and passes data to pass to the service layer. No business logic inside of this layer.
The domain/business layer represents the business/domain logic of the service. This layer doesn’t care about transport and must not depend on it. All business logic must be implemented in this layer.
The store layer represents the behavior of the data store. It can be implemented using PostgreSQL, MongoDB, etc. databases, this is the internal implementation. Only the store layer knows about the kind of database inside. Data just come from the outside of this layer. No business logic inside of this layer.

The most important thing about clean architecture is to make interfaces through each layer. Don’t build dependencies on implementations, use interfaces instead. Each of these layers has its own interface that describes the behavior of it.

Web service:

This service provides the REST API of the platform. Requests from users are handled by rest-api-svc and redirected to other RPC services.

We use Swagger to describe REST API of the project.