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
Domain

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.

  1. 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.

  2. Architecture

    Port, adapter, domain and application layers, plus an inbound MCP adapter so external tools can call your app’s capabilities.

  3. 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.

  4. CLI and code generation

    Generate models, migrations and every inbound or outbound adapter with one command. Ports, registrations, tests and mocks come along.

  5. Development workflow

    Model, migration, domain logic, inbound adapters, outbound adapters, tests and mocks, then run in HTTP, message or workflow mode.

  6. Testing

    Unit-test the domain with mocked ports, with coverage reports and a retry helper for flaky tests.

  7. Deployment

    Docker out of the box via prabogo-cli build. Run on Docker Compose, Kubernetes, or AWS, GCP and Azure container services.

  8. 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.

  9. AI agents

    Spec-driven development with Spec Kit (constitution, specify, plan, tasks, implement), plus Entire.io checkpoints that keep the reasoning behind each change.

  10. Best practices

    Follow the cmd / internal / domain / port / adapter structure, keep logic in the domain, apply DDD boundaries, and test the domain thoroughly.

A blue umbrella, packed and ready

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.

Install
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.