Go Springfield Bank
Go Springfield Bank is a simple digital bank API. Its main purpose is to transfer amounts between internal accounts.
Written in Golang, this project aims to follow Go best practices and
the clean architecture for better
maintainability, extensibility and testability.
Table of Contents
Features
Demo / Deployment
A GitHub Action is configured to compile, test, build a docker image and deploy to Heroku.
The application is accessible at https://go-springfield-bank.herokuapp.com/.
Running
You can quickly build and run the application with its dependencies with this command (
requires docker-compose):
make start
You can stop it with:
make stop
Endpoints
The complete API documentation is available at /swagger
.
Demo: https://go-springfield-bank.herokuapp.com/swagger
Accounts
POST /accounts
- Create an account
- accepts the
X-Idempotency-Key
header.
GET /accounts
- Fetch all the accounts
GET /accounts/:id/balance
- Get the balance of an account
Authentication
POST /login
- Authenticate the user and return the access token
- The returned
access_token
must be sent in the Authorization
header for "protected" endpoints using the
format Bearer <access_token>
.
Transfers
POST /transfers
- Protected. Transfer money to another account
- requires the
Authorization
header.
- accepts the
X-Idempotency-Key
header.
GET /transfers
- Protected.Fetch all the transfers related to the logged-in account
- requires the
Authorization
header.
Idempotent requests
Idempotent requests are very useful to prevent accidentally processing the same request/operation twice.
Some endpoints accept the special header X-Idempotency-Key
.
The client should send a unique key per operation, and if retrying the same operation with the same values it should
send the same key. This application will cache the result of that operation and if another request with the
same X-Idempotency-Key
arrives the cached result will be returned.
Redis is used to cache the idempotent responses.
Metrics/Health
The monitoring endpoints listen on a different port for security reasons. The monitoring port number can be changed
using the MONITORING_PORT
environment variable.
GET /metrics
- Prometheus metrics
GET /ready
- Readiness endpoint
GET /live
- Liveness endpoint
Development
Architecture and data flow
Here's a simple sequence diagram that shows the roles of Controllers, Use Cases and Repositories, and how they interact
with each other:
Postgres and Redis servers
The application depends on Postgres and Redis servers.
You can get a Postgres and a Redis server up and running quickly by running (
requires docker-compose):
make dev-up
You can shut them down later by running:
make dev-down
Setup
You can get the application dependencies by running (requires go 1.11+):
make setup
Tests
You can easily run the tests with:
make test
Environment variables
Check definitions and examples of configuration variables used by this app at config/.env.example
.
References
Project layout
Architecture
Error handling
Web server
Authentication and JWT
Tests
Best practices and tips
Git
Idempotent requests