You've already forked golang-saas-starter-kit
mirror of
https://github.com/raseels-repos/golang-saas-starter-kit.git
synced 2025-08-06 22:32:51 +02:00
update readmes
This commit is contained in:
86
README.md
86
README.md
@ -6,55 +6,57 @@ twins@geeksaccelerator.com
|
|||||||
|
|
||||||
## Description
|
## Description
|
||||||
|
|
||||||
The SaaS Starter Kit is a set of libraries for building scalable software-as-a-service applications while preventing both misuse and fraud. The goal of this project is project is to provide a proven starting point for new projects that reduces the repetitive tasks in getting a new project launched to production that can easily be scaled and ready to onboard enterprise clients. It uses minimal dependencies, implements idiomatic code and follows Golang best practices.
|
The SaaS Starter Kit is a set of libraries for building scalable software-as-a-service (SaaS) applications while preventing both misuse and fraud. The goal of this project is project is to provide a proven starting point for new projects that reduces the repetitive tasks in getting a new project launched to production that can easily be scaled and ready to onboard enterprise clients. It uses minimal dependencies, implements idiomatic code and follows Golang best practices. Collectively, the toolkit lays out everything logically to minimize guess work and enable engineers to quickly load a mental model for the project. This inturn will make current developers happy and expedite on-boarding of new engineers.
|
||||||
|
|
||||||
Ultimately the hope is that this project is not be considered a web framework. It is a starter toolkit that provides a set of working examples to handle some of the common challenges for developing SaaS. Coding is a discovery process and with that, it leaves you in control of the developed.
|
This project should not be considered a web framework. It is a starter toolkit that provides a set of working examples to handle some of the common challenges for developing SaaS using Golang. Coding is a discovery process and with that, it leaves you in control of your project’s architecture and development.
|
||||||
|
|
||||||
Starting any new project there are five areas of expertise for an engineer. Based on our experience, a few core decisions were made that help you focus initially on writing the business logic.
|
|
||||||
Micro level - Relies on Postgres to aid with the data semantics that define the data being captured and their relationships.
|
|
||||||
Macro level - Uses POD architecture and design that provides the project foundation.
|
|
||||||
Business logic - Defines an example Golang package that helps illustrate where value generating activities should reside and how the code will be delivered to clients.
|
|
||||||
Deployment and Operations - Integrates with GitLab for CI/CD and AWS for serverless deployments with AWS Fargate.
|
|
||||||
Observability - Implements Datadog to power exposing metrics, logs and request tracing that ensure stable and responsive service for clients.
|
|
||||||
|
|
||||||
|
There are five areas of expertise that an engineer or her engineering team must do for a project to grow and scale. Based on our experience, a few core decisions were made for each of these areas that help you focus initially on writing the business logic.
|
||||||
|
1. Micro level - Since SaaS requires transactions, project implements Postgres. Implementation facilitates the data semantics that define the data being captured and their relationships.
|
||||||
|
2. Macro level - Uses POD architecture and design that provides the project foundation.
|
||||||
|
3. Business logic - Defines an example Golang package that helps illustrate where value generating activities should reside and how the code will be delivered to clients.
|
||||||
|
4. Deployment and Operations - Integrates with GitLab for CI/CD and AWS for serverless deployments with AWS Fargate.
|
||||||
|
5. Observability - Implements Datadog to facilitate exposing metrics, logs and request tracing that ensure stable and responsive service for clients.
|
||||||
|
|
||||||
SaaS product offerings typically provide two main components: an API and a web application. Both facilitate delivering a valuable software based product to clients ideally from a single code base on a recurring basis delivered over the internet.
|
SaaS product offerings typically provide two main components: an API and a web application. Both facilitate delivering a valuable software based product to clients ideally from a single code base on a recurring basis delivered over the internet.
|
||||||
|
|
||||||
The example project is a complete starter-kit for building SasS with GoLang. It provides three example services:
|
The example project is a complete starter kit for building SasS with GoLang. It provides three example services:
|
||||||
* Web API - REST API with JWT authentication that renders results as JSON. This allows clients to develop deep integrations with the project.
|
* Web App - Responsive web application to provide service to clients. Includes user signup and user authentication for direct client interaction.
|
||||||
* Web App - Responsive web application with client signup and user authentication for direct client interaction.
|
* Web API - REST API with JWT authentication that renders results as JSON. This allows clients to develop deep integrations with the project.
|
||||||
* Schema - Tool for initializing of Postgres database and handles schema migration.
|
* Schema - Tool for initializing of Postgres database and handles schema migration.
|
||||||
|
|
||||||
It contains the following features:
|
It contains the following features:
|
||||||
* Minimal web application using standard html/template package.
|
* Minimal web application using standard html/template package.
|
||||||
* Auto-documented REST API.
|
* Auto-documented REST API.
|
||||||
* Middleware integration.
|
* Middleware integration.
|
||||||
* Database support using Postgres.
|
* Database support using Postgres.
|
||||||
* CRUD based pattern.
|
* Key value store using Redis
|
||||||
* Role-based access control (RBAC).
|
* CRUD based pattern.
|
||||||
* Account signup and user management.
|
* Role-based access control (RBAC).
|
||||||
* Distributed logging and tracing.
|
* Account signup and user management.
|
||||||
* Testing patterns.
|
* Distributed logging and tracing.
|
||||||
* Use of Docker, Docker Compose, and Makefiles.
|
* Integration with Datadog for enterprise-level observability.
|
||||||
* Vendoring dependencies with Modules, requires Go 1.12 or higher.
|
* Testing patterns.
|
||||||
* Continuous deployment pipeline.
|
* Use of Docker, Docker Compose, and Makefiles.
|
||||||
* Serverless deployments.
|
* Vendoring dependencies with Modules, requires Go 1.12 or higher.
|
||||||
* CLI with boilerplate templates to reduce repetitive copy/pasting..
|
* Continuous deployment pipeline.
|
||||||
|
* Serverless deployments.
|
||||||
|
* CLI with boilerplate templates to reduce repetitive copy/pasting.
|
||||||
|
* Integration with GitLab for enterprise-level CI/CD.
|
||||||
|
|
||||||
|
|
||||||
## Local Installation
|
## Local Installation
|
||||||
|
|
||||||
Docker is required to run this project on your local machine. This project uses multiple third-party services that will be hosted locally via docker.
|
Docker is required to run this project on your local machine. This project uses multiple third-party services that will be hosted locally via docker.
|
||||||
* Redis - key / value storage for sessions and other data. Used only as ephemeral storage.
|
* Postgres - Transactional database to handle persistence of all data.
|
||||||
* Postgres - Transactional database to handle persistence of all data.
|
* Redis - Key / value storage for sessions and other data. Used only as ephemeral storage.
|
||||||
* Datadog - Provides metrics, logging, and tracing.
|
* Datadog - Provides metrics, logging, and tracing.
|
||||||
|
|
||||||
An AWS account is required for deployment for the following dependencies:
|
An AWS account is required for deployment for the following AWS dependencies:
|
||||||
* Secret manager - Provides store for private key used for JWT.
|
* Secret Manager - Provides store for private key used for JWT.
|
||||||
* S3 - Host static files on S3 with additional CDN support with CloudFront.
|
* S3 - Host static files on S3 with additional CDN support with CloudFront.
|
||||||
* ECS Fargate - Serverless deployments of application.
|
* ECS Fargate - Serverless deployments of application.
|
||||||
* RDS - Cloud hosted version of Postgres.
|
* RDS - Cloud hosted version of Postgres.
|
||||||
* Route 53 - Management of DNS entries.
|
* Route 53 - Management of DNS entries.
|
||||||
|
|
||||||
|
|
||||||
### Getting the project
|
### Getting the project
|
||||||
@ -65,24 +67,30 @@ You can use the traditional `go get` command to download this project into your
|
|||||||
$ go get -u gitlab.com/geeks-accelerator/oss/saas-starter-kit
|
$ go get -u gitlab.com/geeks-accelerator/oss/saas-starter-kit
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
### Go Modules
|
### Go Modules
|
||||||
|
|
||||||
This project is using Go Module support for vendoring dependencies. We are using the `tidy` command to maintain the dependencies and make sure the project can create reproducible builds. This project assumes the source code will be inside your GOPATH within the traditional location.
|
This project is using Go Module support for vendoring dependencies.
|
||||||
|
|
||||||
|
We are using the `tidy` command to maintain the dependencies and make sure the project can create reproducible builds.
|
||||||
|
|
||||||
|
This project assumes the source code will be inside your GOPATH within the traditional location.
|
||||||
|
|
||||||
```
|
```
|
||||||
cd $GOPATH/src/geeks-accelerator/oss/saas-starter-kit/example-project
|
cd $GOPATH/src/geeks-accelerator/oss/saas-starter-kit/example-project
|
||||||
GO111MODULE=on go mod tidy
|
GO111MODULE=on go mod tidy
|
||||||
```
|
```
|
||||||
|
|
||||||
It's recommended to use at least go 1.12 and enable go modules.
|
It is recommended to use at least go 1.12 and enable go modules.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
echo "export GO111MODULE=on" >> ~/.bash_profile
|
echo "export GO111MODULE=on" >> ~/.bash_profile
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
### Installing Docker
|
### Installing Docker
|
||||||
|
|
||||||
Docker is a critical component to managing and running this project.
|
Docker is a critical component and required to run this project.
|
||||||
|
|
||||||
https://docs.docker.com/install/
|
https://docs.docker.com/install/
|
||||||
|
|
||||||
|
@ -6,9 +6,25 @@ twins@geeksaccelerator.com
|
|||||||
|
|
||||||
## Description
|
## Description
|
||||||
|
|
||||||
The example project provides the ability clients to manage projects. New clients can sign up which creates an account and a user with role admin. Two basic roles are available for users: admins and users. Admins have the ability to perform all CRUD actions on projects and users. Those users with role user only have the ability to view projects and users.
|
With SaaS, a client subscribes to an online service you provide them. The example project provides functionality for clients to subscribe and then once subscribed they can interact with your software service. For this example, *projects* will be the single business logic package that will be exposed to users for management based on their role. Additional business logic packages can be added to support your project. It’s important at the beginning to minimize the connection between business logic packages on the same horizontal level.
|
||||||
|
This project provides the following functionality to users:
|
||||||
|
|
||||||
All business logic should be contained as a package outside both the web app and web API. This enables both the web app and web API to use the same API (Golang packages) with the only main difference between them is their response, HTML or JSON.
|
New clients can sign up which creates an account and a user with role of admin.
|
||||||
|
* Users with the role of admin can manage users for their account.
|
||||||
|
* Authenticated users can manage their projects based on RBAC.
|
||||||
|
|
||||||
|
The project implements RBAC with two basic roles for users: admin and user.
|
||||||
|
* The role of admin provides the ability to perform all CRUD actions on projects and users.
|
||||||
|
* The role of user limits users to only view projects and users.
|
||||||
|
|
||||||
|
Of course, this example implementation of RBAC can be modified and enhanced to meet your requirements.
|
||||||
|
|
||||||
|
The project groups code in three distinct directories:
|
||||||
|
* Cmd - all application stuff (routes and http transport)
|
||||||
|
* Internal - all business logic (compiler protections)
|
||||||
|
* Platform - all foundation stuff (kit)
|
||||||
|
|
||||||
|
All business logic should be contained as a package inside the internal directory. This enables both the web app and web API to use the same API (Golang packages) with the only main difference between them is their response, HTML or JSON.
|
||||||
|
|
||||||
|
|
||||||
## Running The Project
|
## Running The Project
|
||||||
@ -31,12 +47,16 @@ Use the `docker-compose.yaml` to run all of the services, including the 3rd part
|
|||||||
$ docker-compose up
|
$ docker-compose up
|
||||||
```
|
```
|
||||||
|
|
||||||
Default configuration is set which should be valid for most systems. Use the `docker-compose.yaml` file to configure the services differently using environment variables when necessary.
|
Default configuration is set which should be valid for most systems.
|
||||||
|
|
||||||
|
Use the `docker-compose.yaml` file to configure the services differently using environment variables when necessary.
|
||||||
|
|
||||||
|
|
||||||
### Stopping the project
|
### Stopping the project
|
||||||
|
|
||||||
You can hit <ctrl>C in the terminal window running `docker-compose up`. Once that shutdown sequence is complete, it is important to run the `docker-compose down` command.
|
You can hit <ctrl>C in the terminal window running `docker-compose up`.
|
||||||
|
|
||||||
|
Once that shutdown sequence is complete, it is important to run the `docker-compose down` command.
|
||||||
|
|
||||||
```
|
```
|
||||||
$ <ctrl>C
|
$ <ctrl>C
|
||||||
@ -49,14 +69,13 @@ Running `docker-compose down` will properly stop and terminate the Docker Compos
|
|||||||
## Web App
|
## Web App
|
||||||
[cmd/web-app](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/web-app)
|
[cmd/web-app](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/web-app)
|
||||||
|
|
||||||
Responsive web application that renders HTML using the `html/template` package from the standard library to enable direct interaction with clients and their users. It allows clients to sign up new accounts and provides user authentication with HTTP sessions. The web app relies on the Golang business logic packages developed to provide an API for internal development.
|
Responsive web application that renders HTML using the `html/template` package from the standard library to enable direct interaction with clients and their users. It allows clients to sign up new accounts and provides user authentication with HTTP sessions. The web app relies on the Golang business logic packages developed to provide an API for internal requests.
|
||||||
|
|
||||||
|
|
||||||
## Web API
|
## Web API
|
||||||
[cmd/web-api](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/web-api)
|
[cmd/web-api](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/web-api)
|
||||||
|
|
||||||
REST API available to clients for supporting deeper integrations. The API implements JWT authentication that renders results as JSON to clients. This API is not directly used by the web app to prevent locking the functionally needed internally for development of the web app to the same functionality exposed to clients. It’s believed that in the beginning, having to define an additional API for internal purposes is worth at additional effort as the internal API can handle more flexible updates. The API exposed to clients can then be maintained in a more rigid/structured process to manage client expectations.
|
REST API available to clients for supporting deeper integrations. This API is also a foundation for third-party integrations. The API implements JWT authentication that renders results as JSON to clients. This API is not directly used by the web app to prevent locking the functionally needed internally for development of the web app to the same functionality exposed to clients. It is believed that in the beginning, having to define an additional API for internal purposes is worth at additional effort as the internal API can handle more flexible updates. The API exposed to clients can then be maintained in a more rigid/structured process to manage client expectations.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Making Requests
|
### Making Requests
|
||||||
@ -86,15 +105,17 @@ $ curl -H "Authorization: Bearer ${TOKEN}" http://localhost:3000/v1/users
|
|||||||
## Schema
|
## Schema
|
||||||
[cmd/schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/schema)
|
[cmd/schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/cmd/schema)
|
||||||
|
|
||||||
Schema is a minimalistic database migration helper that can manually be invoked via CLI. It provides schema versioning and migration rollback. To support POD architecture, the schema for the entire project is defined globally and is located inside internal: [internal/schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/internal/schema)
|
Schema is a minimalistic database migration helper that can manually be invoked via CLI. It provides schema versioning and migration rollback.
|
||||||
|
|
||||||
|
To support POD architecture, the schema for the entire project is defined globally and is located inside internal: [internal/schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/tree/master/example-project/internal/schema)
|
||||||
|
|
||||||
Keeping a global schema helps ensure business logic then can be decoupled across multiple packages. It’s a firm belief that data models should not be part of feature functionality. Globally defined structs are dangerous as they create large code dependencies. Structs for the same database table can be defined by package to help mitigate large code dependencies.
|
Keeping a global schema helps ensure business logic then can be decoupled across multiple packages. It’s a firm belief that data models should not be part of feature functionality. Globally defined structs are dangerous as they create large code dependencies. Structs for the same database table can be defined by package to help mitigate large code dependencies.
|
||||||
|
|
||||||
The example schema package provides two separate methods for handling schema migration.
|
The example schema package provides two separate methods for handling schema migration.
|
||||||
[Migrations](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/blob/master/example-project/internal/schema/migrations.go)
|
* [Migrations](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/blob/master/example-project/internal/schema/migrations.go)
|
||||||
List of direct SQL statements for each migration with defined version ID. A database table is created to persist executed migrations. Upon run of each schema migration run, the migraction logic checks the migration database table to check if it’s already been executed. Thus, schema migrations are only ever executed once. Migrations are defined as a function to enable complex migrations so results from query manipulated before being piped to the next query.
|
List of direct SQL statements for each migration with defined version ID. A database table is created to persist executed migrations. Upon run of each schema migration run, the migraction logic checks the migration database table to check if it’s already been executed. Thus, schema migrations are only ever executed once. Migrations are defined as a function to enable complex migrations so results from query manipulated before being piped to the next query.
|
||||||
[Init Schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/blob/master/example-project/internal/schema/init_schema.go)
|
* [Init Schema](https://gitlab.com/geeks-accelerator/oss/saas-starter-kit/blob/master/example-project/internal/schema/init_schema.go)
|
||||||
If you have a lot of migrations, it can be a pain to run all them, as example, when you are deploying a new instance of the app, in a clean database. To prevent this, use the initSchema function that will run if no migration was run before (in a new clean database). Remember to create everything here, all tables, foreign keys and what more you need in your app.
|
If you have a lot of migrations, it can be a pain to run all them, as an example, when you are deploying a new instance of the app, in a clean database. To prevent this, use the initSchema function that will run if no migration was run before (in a new clean database). If you are using this to help seed the database, you will need to create everything needed, all tables, foreign keys, etc.
|
||||||
|
|
||||||
Another bonus with the globally defined schema allows testing to spin up database containers on demand include all the migrations. The testing package enables unit tests to programmatically execute schema migrations before running any unit tests.
|
Another bonus with the globally defined schema allows testing to spin up database containers on demand include all the migrations. The testing package enables unit tests to programmatically execute schema migrations before running any unit tests.
|
||||||
|
|
||||||
@ -126,12 +147,9 @@ DD_EXPVAR=service_name=web-app env=dev url=http://web-app:4000/debug/vars|servic
|
|||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### AWS Permissions
|
### AWS Permissions
|
||||||
|
|
||||||
Base required permissions
|
Base required permissions.
|
||||||
```
|
```
|
||||||
secretsmanager:CreateSecret
|
secretsmanager:CreateSecret
|
||||||
secretsmanager:GetSecretValue
|
secretsmanager:GetSecretValue
|
||||||
@ -140,17 +158,18 @@ secretsmanager:PutSecretValue
|
|||||||
secretsmanager:UpdateSecret
|
secretsmanager:UpdateSecret
|
||||||
```
|
```
|
||||||
|
|
||||||
If cloudfront enabled for static files
|
Additional permissions required for unit tests.
|
||||||
```
|
|
||||||
cloudFront:ListDistributions
|
|
||||||
```
|
|
||||||
|
|
||||||
Additional permissions required for unittests
|
|
||||||
```
|
```
|
||||||
secretsmanager:DeleteSecret
|
secretsmanager:DeleteSecret
|
||||||
```
|
```
|
||||||
|
|
||||||
|
The example web app service allows static files to be served from AWS CloudFront for increased performance. Enable for static files to be served from CloudFront instead of from service directly.
|
||||||
|
```
|
||||||
|
cloudFront:ListDistributions
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
## What's Next
|
## What's Next
|
||||||
|
|
||||||
We are in the process of writing more documentation about this code.
|
We are in the process of writing more documentation about this code. We welcome you to make enhancements to this documentation or just send us your feedback and suggestions ; )
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user