What Is Plumego

Plumego is a minimal service framework for Go, built directly on top of the Go standard library.

It exists to solve a specific class of problems:

How to build Go services that remain understandable, maintainable, and evolvable over a long period of time — without being locked into a heavy framework or ecosystem.

Plumego is not a general-purpose “everything included” framework.
It is an engineering skeleton: a small, carefully constrained foundation that defines how requests flow through a system, while leaving most decisions explicitly in the hands of engineers.

The Problem Plumego Is Trying to Solve

Go’s standard library is powerful, stable, and intentionally minimal.
However, when building real-world services directly on net/http, teams often encounter the same problems repeatedly:

Inconsistent project structure across services
Ad-hoc middleware implementations
Unclear request lifecycle boundaries
Context misuse or overuse
Framework logic leaking into business logic
Difficulty evolving architecture without large refactors

These problems are not caused by Go.
They are caused by the absence of a shared, disciplined structure.

Plumego exists to provide that structure — without replacing the standard library.

What Plumego Is

At its core, Plumego provides:

A clear request lifecycle model
A disciplined router and middleware composition
A thin, explicit Context abstraction
A strict boundary between framework and business logic
A default architectural shape that can be copied and evolved

Plumego does not attempt to hide how HTTP works.
It makes the flow of a request more explicit, not more abstract.

In practical terms, Plumego helps you answer questions like:

Where does a request enter the system?
Where do cross-cutting concerns live?
Where should business logic stop depending on the framework?
How can this service be changed five years from now?

What Plumego Is Not

Equally important is understanding what Plumego deliberately does not try to be.

Plumego is not:

A batteries-included web framework
A microservices platform
An ORM or data-access abstraction
A dependency injection container
A code generator
A plugin-driven ecosystem

If you are looking for a framework that:

Maximizes development speed
Provides dozens of built-in integrations
Minimizes the amount of code you write
Makes architectural decisions for you

Plumego is likely not a good fit.

A Framework That Assumes Engineering Responsibility

Plumego is designed around a core assumption:

Frameworks should not replace engineering judgment.

Instead of offering convenience through hidden behavior, Plumego offers:

Explicit composition
Predictable execution order
Minimal abstractions
Clear ownership of decisions

This means Plumego may feel “verbose” compared to some frameworks —
but that verbosity is intentional.

Every explicit line of code is treated as documentation for future maintainers.

Plumego and the Go Standard Library

Plumego treats the Go standard library as a foundation, not a problem to be abstracted away.

Key design choices include:

Using net/http directly rather than reimplementing it
Building on context.Context instead of replacing it
Avoiding reflection-heavy or magic-driven behavior
Preferring composition over inheritance or code generation

As a result:

Debugging behavior is easier to reason about
Standard tooling continues to work as expected
Upgrading Go versions carries minimal risk
Engineers can always “drop down” to the standard library when needed

Plumego as an Engineering Skeleton

A useful mental model is to think of Plumego as scaffolding, not a finished building.

It defines:

The shape of request handling
Where framework code should end
Where application code should begin

But it does not define:

Your domain model
Your persistence strategy
Your service boundaries
Your infrastructure choices

This makes Plumego suitable for a wide range of systems, including:

Internal services
Long-lived APIs
Platform and tooling backends
Game servers and real-time systems
Infrastructure-facing services

As long as long-term maintainability matters, Plumego can fit.

Why Plumego Exists Despite Existing Frameworks

Plumego is not an attempt to replace existing Go frameworks.

Those frameworks solve real problems, often very well.

Plumego exists because there is a gap between:

Using a full-featured framework
Writing everything directly on net/http

That gap is where long-lived, engineering-focused systems often struggle.

Plumego intentionally occupies that space.

A Note on Longevity

Plumego is designed with the assumption that:

The original authors may not maintain the system forever
The codebase will be read far more often than it is written
Architectural decisions will need to be revisited over time

As a result, Plumego prioritizes:

Clarity over cleverness
Stability over novelty
Explicitness over convenience

Summary

In short:

Plumego is a minimal Go service framework
It is standard-library-first
It provides structure, not solutions
It optimizes for long-term maintainability
It assumes engineering responsibility, not framework magic

If these goals align with your project, continue reading.

If they do not, Plumego encourages you to stop here —
that is a successful outcome, not a failure.

To understand why Plumego makes these choices, continue with:

→ Design Philosophy