Practical backend oriented on go · #Prabogo
Why would anyone carry an umbrella on a sunny day?
This is the story of why Prabogo exists, and what it packs for the weather you can’t see yet.
01 — The clear day
Every backend starts simple
One endpoint. One table. A handler that talks straight to the database. It works, it ships, and everyone is happy. The sun is out.
Then the “just one more” begins: one more queue, one more integration, one more flag, one more person who solves it their own way. Somehow the simple thing becomes the complicated thing.
02 — The forecast
Now look forward
A great backend isn’t judged on a clear day. It’s judged by the storm it will meet later. Nobody knows exactly when, but we know the kinds of weather coming.
-
Traffic
Load that grows exponentially, not politely.
-
Data
Tables and events that turn massive.
-
Change
New technology arriving in ways no one predicted.
-
People
Many teammates. If everyone works their own way, maintenance becomes pain.
03 — The case for early
“It looks ridiculous. The sun is so bright.”
Preparing for all of this at the start does look absurd. It looks like opening an umbrella under a blue sky.
But the umbrella matters when the rain starts, and it matters even more in the storm. You can’t buy it once the lightning is overhead.
04 — The answer
Meet Prabogo
A modern Go framework built on hexagonal architecture (ports and adapters). Business logic sits in the middle and knows nothing about the outside world. Everything else plugs in.
Inbound adapters
- HTTP (Fiber)
- RabbitMQ consumer
- Temporal workflow
- MCP tools
- CLI command
Business rules
Outbound adapters
- PostgreSQL
- Redis cache
- HTTP client
- RabbitMQ publisher
- Temporal starter
- Swap a database, a broker or a server with minimal code changes.
- Test the domain in isolation.
- One shared structure for the whole team.
05 — The docs
The docs, in one scroll
Ten short summaries of what is already written down. The full text lives over at the docs site.
-
Getting started
Needs Go 1.24 or newer. Docker Compose and fzf are optional. Install the CLI, pick your stack, and run
prabogo-cli run. -
Architecture
Port, adapter, domain and application layers, plus an inbound MCP adapter so external tools can call your app’s capabilities.
-
Authorization
Chosen by
AUTH_DRIVER. Internal bearer keys are simple (pair them with mTLS). Authentik JWT with JWKS validation is the recommended, scalable option with SSO. -
CLI and code generation
Generate models, migrations and every inbound or outbound adapter with one command. Ports, registrations, tests and mocks come along.
-
Development workflow
Model, migration, domain logic, inbound adapters, outbound adapters, tests and mocks, then run in HTTP, message or workflow mode.
-
Testing
Unit-test the domain with mocked ports, with coverage reports and a retry helper for flaky tests.
-
Deployment
Docker out of the box via
prabogo-cli build. Run on Docker Compose, Kubernetes, or AWS, GCP and Azure container services. -
Observability
OpenTelemetry with the Grafana LGTM stack (Loki, Grafana, Tempo, Mimir). Request metrics, a span per domain operation, and secrets masked in every log line.
-
AI agents
Spec-driven development with Spec Kit (constitution, specify, plan, tasks, implement), plus Entire.io checkpoints that keep the reasoning behind each change.
-
Best practices
Follow the
cmd / internal / domain / port / adapterstructure, keep logic in the domain, apply DDD boundaries, and test the domain thoroughly.
06 — The habit
Pack the umbrella now
Prabogo is the habit of preparing while it’s sunny, so that when traffic surges, data swells and technology shifts, the team keeps walking.
go install github.com/prabogo/prabogo-cli@latest
prabogo-cli install my-project-name
cd my-project-name && prabogo-cli run
Still curious?
There is more about the values behind the code in my writing, and I am always happy to talk about architecture.