Docs Can I Use Plumego With X?

Can I Use Plumego With X?

A very common question when evaluating Plumego is:

“Can I use Plumego with X?”

Where X might be:

  • A logging library
  • An ORM
  • A DI container
  • A message queue
  • gRPC
  • GraphQL
  • OpenTelemetry
  • Kubernetes
  • A cloud provider
  • Another framework

The short answer is almost always:

“Yes — if X does not try to own what Plumego intentionally leaves to you.”

This page explains how to decide, without maintaining a fragile compatibility list.

The Wrong Way to Ask This Question

The wrong question is:

“Does Plumego officially support X?”

Plumego does not curate an official integration matrix.

Why?

Because that would imply:

  • Hidden assumptions
  • Blessed stacks
  • Coupling framework evolution to external tools

Plumego avoids all three.

The Right Question to Ask

The right question is:

“Does X require implicit control over lifecycle, configuration, or control flow?”

If the answer is no, integration is usually straightforward.
If the answer is yes, friction is expected.

Plumego’s Integration Model (One Rule)

Plumego follows a single integration rule:

“Plumego is just an http.Handler with explicit boundaries.”

Anything that can work with:

  • net/http
  • Explicit construction
  • Manual wiring
  • Clear ownership

Can work with Plumego.

Categories of Tools and How They Fit

1. Logging Libraries (Zap, Zerolog, Logrus, etc.)

✅ Yes, naturally compatible

Why:

  • Logging is injected
  • No framework-level logging
  • No lifecycle ownership

Pattern:

  • Construct logger at startup
  • Inject into middleware and usecases

If a logging library requires global state, you decide whether to use it —
Plumego does not force it.

2. Databases and ORMs (sqlx, GORM, Ent, raw SQL)

✅ Yes, with clear boundaries

Why:

  • Persistence is outside the framework
  • Usecases own repositories
  • No ORM hooks in the framework

Guideline:

  • Do not pass DB handles through Context
  • Do not let ORM types leak into handlers
  • Keep repositories explicit

Plumego does not care how you persist —
only that boundaries remain explicit.

3. Dependency Injection Containers

⚠️ Technically possible, philosophically discouraged

Why:

  • Most DI containers rely on reflection
  • Implicit wiring hides dependencies
  • Lifecycle ownership becomes unclear

If you use one:

  • Keep it at the composition root
  • Do not let it leak into handlers or usecases
  • Do not let it replace explicit thinking

Plumego will not integrate with DI containers directly.

4. Message Queues / Event Systems (Kafka, NATS, SQS, etc.)

✅ Yes, explicitly

Why:

  • Background work is external by design
  • Async boundaries are encouraged
  • Integration happens in handlers or workers

Pattern:

  • Handler publishes event
  • Worker consumes event
  • No implicit coupling to request lifecycle

Plumego documents how to do this,
not what to use.

5. gRPC / RPC Systems

✅ Yes, at boundaries

Common patterns:

  • Plumego for HTTP APIs
  • gRPC for internal service-to-service calls
  • Shared usecases underneath

Important:

  • Do not mix HTTP Context with gRPC Context
  • Treat transports as adapters
  • Share domain logic, not transport logic

Plumego plays well in mixed-transport systems.

6. GraphQL

⚠️ Possible, but be deliberate

GraphQL servers often:

  • Own execution flow
  • Perform validation internally
  • Manage error semantics centrally

If embedding GraphQL:

  • Treat it as a handler
  • Keep Plumego as the HTTP boundary
  • Do not let GraphQL subsume architecture

GraphQL fits better inside Plumego than instead of it.

7. Observability (OpenTelemetry, Prometheus, etc.)

✅ Yes, cleanly

Why:

  • Middleware is explicit
  • Trace IDs can be injected
  • Metrics are orthogonal

Pattern:

  • Tracing middleware
  • Context enrichment (carefully)
  • Explicit propagation across boundaries

Plumego avoids “observability magic” by design.

8. Kubernetes / Cloud Providers

✅ Yes, naturally

Why:

  • Plumego does not assume deployment model
  • No process ownership
  • No runtime assumptions

Plumego runs anywhere net/http runs.

9. Other Web Frameworks

⚠️ Usually unnecessary

If you ask:

“Can I use Plumego together with Gin / Echo / Fiber?”

That usually indicates:

  • Conflicting ownership
  • Redundant abstractions
  • Increased cognitive load

If needed:

  • Use one as the outer router
  • Treat the other as a black-box handler

But prefer choosing one.

A Simple Compatibility Checklist

Before integrating X with Plumego, ask:

  1. Does X require global state?
  2. Does X require hidden lifecycle hooks?
  3. Does X mutate control flow implicitly?
  4. Does X assume it owns configuration?
  5. Does X obscure error handling?

If most answers are “yes”,
integration will feel awkward — by design.

Why Plumego Rarely Says “No”

Plumego almost never forbids integrations.

Instead, it makes incompatibilities visible.

If something feels painful to integrate,
that pain is usually a signal about ownership boundaries —
not missing features.

Summary

You can use Plumego with almost anything that:

  • Respects explicit construction
  • Does not demand hidden control
  • Integrates via clear boundaries
  • Accepts manual wiring

Plumego does not ask:

“Does this tool fit the framework?”

It asks:

“Does this tool respect your ability to reason about your system?”

If the answer is yes,
Plumego will stay out of the way.

  • Common Mistakes
  • Why Is Plumego So Explicit?
  • When Not to Use Plumego
  • Plumego vs Gin / Echo

Compatibility is not about checklists —
it is about who owns the complexity.