This is just a quick article to describe how the GoConSPA stack implements the 15 Factor App principles.

1. One Codebase, Ont Application

• GitHub: All code for the application is stored in a single repository.

2. API First

• ConnectRPC: The api is defined in protobuf, and exposed via ConnectRPC.

3. Dependencies

• Go Modules: All dependencies are managed via Go modules, and vendored in the repository.

4. Configuration

• GitOps: Configuration is stored in Git, allowing for version control and easy collaboration.
• ** Environment Variables**: Configuration is stored in environment variables, and loaded via viper.
• ** YAML Configuration**: Configuration is stored in YAML files, and loaded via viper.

5. Backing Services

• Docker: All backing services are run in Docker containers, and managed via docker-compose.

6. Build, Release, Run

• GitHub Actions: All builds are done via GitHub Actions, and released to a container registry.

7. Processes (Statelessness)

• Stateless Services: All services are stateless, and can be scaled horizontally.

8. Port Binding

• HTTP/2: All services are exposed via HTTP/2, and can be accessed via a load balancer.

9. Concurrency

• Docker: All services are run in Docker containers - no PID files, daemons, or init systems.

10. Disposability

• Docker: All services are run in Docker containers, and can be started and stopped quickly.

11. Log (streamiing)

• Docker: All logs are written to stdout and stderr, and can be collected via a log collector.

12. Admin Processes

• Docker: All admin processes are run in Docker containers - which mirror the production environment.

13. APi First

• ConnectRPC: The api is defined in protobuf, and exposed via ConnectRPC.

14. Telemetry

• Prometheus: All services expose metrics in a standard format, and can be scraped by Prometheus.

15. Authentication

• OAuth2: All services use OAuth2 for authentication, and can be accessed via a token.

I’m eager to write about a technology stack that I’ve stumbled into, which I believe is the nicest one I’ve ever worked with. The stack is called GoConnSPA, and it consists of the following technologies and tools;

Overview

  flowchart TD
    A[Backend Service] <-->|websocket| B[Single Page App]

Technologies

• Go: The Go programming language, which is known for its simplicity and efficiency.
• ConnectRPC: A gRPC framework for Go that simplifies the process of building and consuming gRPC services.
• SPA (+CSR): Single Page Application with client side rendering - not reliant on the server.

Tools

• Air: A live reloading tool for Go applications, which automatically reloads the application when code changes are detected.
• Vite: A build tool that provides a fast development environment and optimizes the build process for production.
• Goreleaser: A tool for building and releasing Go applications, making it easy to create binaries and publish them to various platforms.
• precommit: A framework for managing and maintaining multi-language pre-commit hooks, ensuring code quality and consistency.
  • conventional-pre-commit: A pre-commit hook that enforces conventional commit messages, helping to maintain a clean and understandable commit history.
• GitHub Actions: A CI/CD tool that allows you to automate your software development workflows directly in your GitHub repository.
  • goreleaser-action: A GitHub Action that integrates with Goreleaser, automating the process of building and releasing Go applications.
  • semantic-release-action: A GitHub Action that automates the release process based on semantic versioning, ensuring that releases are consistent and predictable.
• Docker: Just release containers

I’m just throwing this blog post out there to get it started, and because otherwise I’ll never find the time to finish the perfect blog post. However, I’ve ported the majority of projects I maintain to use this stack now.

It can be a real effort to bring yourself to write articles to maintain a healthy blog, and sometimes the simple articles are best. Therefore, I just want to take a quick few moments to talk about a tool that I just cannot live without now-a-days, when writing Go code, I am always live-reloading with Air in the background.

It’s really valuable for developers to be able to get fast feedback on the code that they are writing. Many of use will use one monitor for the code in web applications, for example, and another monitor for the web browser to quickly glance to the side, and refresh the page. However with non-web applications, it can be a little more tedious to compile, re-run tests, and run the application once again. Of course it isn’t difficult - most developers of microservices and similar will have a terminal window open on that second monitor, and they’ll hit Up on the keyboard to get the last command, make, ./myapp, etc.

This helps you use Go to power the next generation of APIs+PWAs.

Prerequisites; This article assumes you know what protobuf and gRPC are, and have set up the grpc-gateway for REST already for your app.

The context

gRPC has become the default standard for modern Cloud Native RPC in Go. And gRPC is fine for backend service-to-service communication that can speak gRPC. To support older services, and the web, REST still reigns supreme.