Golang clean architecture using mvc pattern

---

Table of Contents

• Introduction
• What does the code do?
• How to run the code?
• Structure
• Recommendations

Introduction

This is a simple example of how to use mvc pattern in golang. Some of the code is inspired by everone/go-clean-template but since it was too complex for me, I made my own version.

What does the code do

The code is a simple REST API that allows you to create, read, update users. There are admins and regular users. Admins can do everything, regular users can only read and update their own data. If you want a better documentation of the API you can check the swagger file or you can run the server and go to localhost:8080/swagger/index.html to see the documentation. Not all functionalities are implemented as the code is not the main focus of this example.

How to run the code?

After cloning the repo you need to run the following commands:

using make:

make run

using go:

go mod download
go run .

or you can use docker:

docker build -t mvc-clean-template .
docker run -p 8080:8080 mvc-clean-template

p.s. you can run make docker to build the docker image and run it.

Structure

config

The config folder contains the config.yml file and the code that parse the file and returns a struct with the data. If there are environment variables that match the flag in the struct they overwrite the file (this is useful for docker). I used ilyakaznacheev/cleanenv to parse the file so you can check the documentation for more info and make your own changes.

controllers

The controller is the core component of the mvc pattern. This layer is the business logic of the application. It calls the model layer to run a crud operation of the database and then returns the response to the view which responds to the user.

It is important to note that the controller layer should not have any dependencies with the view layer. This is because the controller layer should be unaware of how the request is made so the functions should not handle the http request directly but only recive the data necessary to run the crud operation, by doing this you can change the view layer without changing the controller (by doing so you can add different view layers such as http, cli, gRPC, message queue, etc).

models

The model layer is the layer that has the data structure. This layer contains the structs that represent the data in the database in a readable way by the controller layer, this is because the controller layer should not know how the data is stored in the database (for the same reason as it should not know how the request is made). Also we use interfaces to define a model layer so that all layers implemented have the same methods and we can change the database without changing the controller layer (for example we can use a mock db for testing and a real db for production). The model does not have any logic, it only contains the structs used in the application.

repo

The repo folder contains the code that interacts with the database making the queries and returning the data as a model struct. This code is called by the controller.

handlers

The only "missing" layer in the mvc pattern is the view layer, but the view is the layer that show the user the response of the controller so in other words the view is the controller and since we are making an api we dont have to worry about that hell. We are gonna use as our view the handlers folder, this folder contains the code that directly interacts with the requests made by the "outside", so for example, the http requests or a messaging queue listener. What these components do is validating the request and calling the controller.

pkg

The pkg folder contains the code that is used by the other packages and layers, it's not a pattern layer but just a golang convention to use a pkg folder to store the utility code and internal libraries.

docs

Since this project will use swagger as a documentation tool, the docs folder contains the autogenerated swagger file. (more info about swagger in the recommendations section)

main.go

This file is the entry point of the application, it reads the config, created the objects and then starts the server.

services

This is not a standard folder but I added it cause it's something that i personally do, this folder is similar to the repo folder but it contains the code that interacts with external services such as email, external apis, etc.

Recommendations

I recommend using Postman to test the API as it is much easier than using curl for complex requests. Then rememeber the keep updated your config.example.yml file with the struct of the config.yml file to keep everyone in sync. Since swagger has a nice tool that easily integrate with golang code to autogenerate the documentation file this example will use this tool swaggo/swag