I have designed go-gotham boilerplate adhering to SOLID principles for developers to help them create RESTful API. I take advantage of some other libraries however, I did not neglect to add my codes into it. The aim of this boilerplate is to provide developers a common functionality which will make writing APIs efficient, convenient and testable.
- Di ( https://github.com/sarulabs/di )
- Echo ( https://echo.labstack.com )
- Gorm (https://gorm.io)
- Ozzo-Validation (https://github.com/go-ozzo/ozzo-validation)
- Echo Swagger (https://github.com/swaggo/echo-swagger)
- GoCron (https://github.com/jasonlvhit/gocron)
You can start using this repository by cloning it.
git clone https://github.com/tolgaOzen/go-gotham
change with your database credentials
#DB
DB_CONNECTION=mysql
DB_USERNAME=admin
DB_DATABASE=gotham
DB_HOST=gotham-test
DB_PORT=3306
DB_PASSWORD=strong_password- prevents re-creating container methods from definitions
go run gotham -production
- run migrate methods of repositories before start
go run gotham -migrate
- run seed methods of repositories before start
go run gotham -seed
/
|- app
|- container
|- defs
|- flags
|- provider
app.go
|- config
|- controllers
|- database
|- migrations
|- seeds
|- docs
|- helpers
|- infrastructures
|- mails
|- middlewares
|- models
|- scopes
|- policies
|- repositories
|- transactions
|- requests
|- routers
|- rules
|- services
|- utils
|- viewModels
|- views - (for mails)
main.go
.env
The container part is the part that all of our objects are injected through interfaces, as we specified in definitions.
Controllers are the handlers of all requests coming to the route. The controller can implement interfaces to many services to meet the needs of the request. The controller must be unaware of the logic of the services.
Middlewares work before the request reaches the controller. These are the parts where you can perform authorization check, record requests, limit the number of requests etc. Middlewares can implement service interfaces. This way, they can check the data.
Policies folder consists of sections that check if the authorized user is eligible to perform this action.
Services folder is where the business logic is based. It is responsible for processing the request from the controller. It takes data from the data layer (repositories) and works to meet what the controller expects.
Repositories folder is the data access layer. All database queries made must be performed in the repositories.
Models folder hosts all structs under models namespace, model is a struct reflecting our data object from / to database. models should only define data structs, no other functionalities should be included here.
ViewModels folder hosts all the structs under viewmodels namespace, viewmodels are model to be use as a response return of REST API call
Tolga Özen
MIT License
Copyright (c) 2021 Tolga Özen
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.