go/go-micro
1
0
Fork 0
mirror of https://github.com/go-micro/go-micro.git synced 2025-11-23 21:44:41 +02:00
Code Issues Releases Activity
Files
8cda829320a7911c8b2814365e4645d991936edd
go-micro/internal/website/docs/architecture/adr-001-plugin-architecture.md
Asim Aslam 8cda829320 major docs overhaul
2025-11-13 18:34:40 +00:00

2.4 KiB
Raw Blame History

layout
layout
default

ADR-001: Plugin Architecture

Status

Accepted

Context

Microservices frameworks need to support multiple infrastructure backends (registries, brokers, transports, stores). Different teams have different preferences and existing infrastructure.

Hard-coding specific implementations:

  • Limits framework adoption
  • Forces migration of existing infrastructure
  • Prevents innovation and experimentation

Decision

Go Micro uses a pluggable architecture where:

  1. Core interfaces define contracts (Registry, Broker, Transport, Store, etc.)
  2. Multiple implementations live in the same repository under interface directories
  3. Plugins are imported directly and passed via options
  4. Default implementations work without any infrastructure

Structure

go-micro/
├── registry/          # Interface definition
│   ├── registry.go
│   ├── mdns.go       # Default implementation
│   ├── consul/       # Plugin
│   ├── etcd/         # Plugin
│   └── nats/         # Plugin
├── broker/
├── transport/
└── store/

Consequences

Positive

  • No version hell: Plugins versioned with core framework
  • Discovery: Users browse available plugins in same repo
  • Consistency: All plugins follow same patterns
  • Testing: Plugins tested together
  • Zero config: Default implementations require no setup

Negative

  • Repo size: More code in one repository
  • Plugin maintenance: Core team responsible for plugin quality
  • Breaking changes: Harder to evolve individual plugins independently

Neutral

  • Plugins can be extracted to separate repos if they grow complex
  • Community can contribute plugins via PR
  • Plugin-specific issues easier to triage

Alternatives Considered

Separate Plugin Repositories

Used by go-kit and other frameworks. Rejected because:

  • Version compatibility becomes user's problem
  • Discovery requires documentation
  • Testing integration harder
  • Splitting community

Single Implementation

Like standard net/http. Rejected because:

  • Forces infrastructure choices
  • Limits adoption
  • Can't leverage existing infrastructure

Dynamic Plugin Loading

Using Go plugins or external processes. Rejected because:

  • Complexity for users
  • Compatibility issues
  • Performance overhead
  • Debugging difficulty

Related

  • ADR-002: Interface-First Design (planned)
  • ADR-005: Registry Plugin Scope (planned)