go-spring

Go-Spring: Make Go Service Development as Simple as Spring Boot, and Then Some

If you think this is just another Go framework, keep reading.

Go-Spring's mission is building a complete, vendor-neutral application ecosystem for Go — the assembly layer the Go ecosystem is missing: DI libraries ship parts, framework ecosystems orbit their own transport, component libraries don't know each other. Go-Spring assembles them all.

It takes the battle-tested paradigms from two decades of Java Spring — dependency injection, auto-configuration, the Starter mechanism — and reimagines them in idiomatic Go. Spring rescued Java from EJB hell, turning heavyweight applications into composable, reusable, modular engineering. Go-Spring aims to give Go developers that same superpower.

That mission matters more in the AI era, not less. As AI writes more and more of the code, the scarce resource stops being typing speed and becomes the substrate: a stable, complete, self-describing foundation that both people and agents can build on — and be held to. Go-Spring is built to be that foundation — 90+ Starters behind one configuration model, one application lifecycle and a single machine-checked observability contract, with the project's engineering conventions written down next to the code (starter/DESIGN.md, per-module DESIGN / USAGE docs, and the /gs Claude Code Skill).

The Ecosystem

Go-Spring is not a single repository — it's a complete R&D ecosystem composed of a core framework, an ecosystem abstraction library, 90+ Starters, developer tooling, example applications, and project templates. The layers are strictly ordered — dependencies flow one way, downward — and each layer has a clear role; use what you need.

The rule of thumb that keeps the stack clean: abstractions go in cloud, third-party SDKs and gs wiring go in a starter, pure semantics with no ecosystem dependency go in stdlib — a starter wires, cloud abstracts, spring runs.

What that adds up to today: 90+ starter modules — 6 web frameworks plus the stdlib HTTP server, 8 RPC frameworks, 12 database engines, 4 caches, 7 message queues, 7 configuration sources, 5 registries, 4 distributed locks and 3 transaction models, plus object storage, mail, webhooks, scheduling, batch, gateway and security. They are configured through the same layered engine and join the same application lifecycle; most share a single governance center and observability model, and where a component brings a mature ecosystem of its own, the integration adapts to it rather than the other way round. Swapping a backend is a configuration change, not a rewrite: the abstraction is neutral, so nothing around it has to move.

The design constraints every starter follows live in starter/DESIGN.md; a categorized tour of the modules is in starter/README.md.

Why Go-Spring

The Mission: Completing the Go Ecosystem

Go's standard library is famously complete for a language runtime — and deliberately minimal at the application level: no dependency-injection model, no layered-configuration convention, no starter-style auto-configuration, no unified application lifecycle or governance layer. Java fills that gap with Spring; Go has nobody filling it — DI libraries ship parts, framework ecosystems orbit their own transport, component libraries don't know each other.

Go-Spring exists to fill exactly that gap: building a complete, vendor-neutral application ecosystem for Go — not another RPC framework, not another web framework, and not a rewrite of anything you already use. It competes with nothing in your stack; it assembles your stack.

Who else plays this seat? An honest landscape:

The neutral Spring-Boot-shaped application platform for Go is an essentially empty niche. That is the seat Go-Spring takes.

Not Another RPC Framework — an Application Platform

This is the sharpest day-to-day difference from projects like dubbo-go, Kitex, Kratos, or go-zero: those are (primarily) RPC / microservice frameworks — they own the transport layer, the service model, and often a code-generation pipeline. Your application is a dubbo application or a Kitex application; adopting one means adopting its programming model.

Go-Spring owns no protocol and no transport. It is the assembly and runtime layer beneath and beside them: dependency injection, layered configuration with hot reload, lifecycle management, and centralized service governance. Proof by construction — in this very repository, dubbo-go, Kitex, Kratos, go-zero, GoFrame, gRPC, tRPC, and Thrift each appear as one Starter among 90, integrated by the same gs.Module mechanism as Redis or MySQL:

In short: they answer "how do services call each other"; Go-Spring answers "how an application is assembled, configured, governed, and kept maintainable". A production service typically needs both — which is why Go-Spring integrates them rather than competing with them. (For the DI-framework axis — Wire/fx/dig — see the comparison in spring/README.md.)

Out-of-the-Box, Zero Intrusion

Every capability ships as a Starter. No inheritance, no adapters, no sprawling initialization boilerplate in main.go — import a starter and it automatically wires your components into the application lifecycle. The framework doesn't hijack main(), doesn't impose routing groups, doesn't mandate a directory layout. You write business logic your way; the framework handles assembly and lifecycle.

Observability: Complete by Default, Extensible by Design

Observability is where an "ecosystem of parts" usually falls apart: every library brings its own idea of what a metric is called, and the moment you swap a backend your dashboards, alerts and queries stop meaning anything. Go-Spring treats it as a contract instead.

• Every component is instrumented — not opt-in. All 54 instrumented components (the database, messaging, HTTP and RPC families, plus the cloud domain packages) emit their signals under one specification, where a missing signal — or a result value that can't tell success from failure — counts as a defect rather than a style difference. Coverage includes the operations the framework performs on your behalf: discovery heartbeats, lock acquisition, cache and MQ access, not just your own handlers.
• Same vocabulary across same-kind components. Components of the same kind share names, instrument types and value vocabularies, following OpenTelemetry semantic conventions (db.system, messaging.system, http.*). Trade Redis for Memcached, or Kafka for Pulsar, and your operations assets keep reading the same way. Components are still free to add their own fields — consistency is required only where the meaning is the same.
• Enforced by a script, not by good intentions. scripts/check-observability.sh mechanically verifies the specification across all 54 components, and scripts/check-all.sh runs it on every push and PR — drift breaks the build instead of quietly rotting.
• Your own data goes in without forking the framework. Annotate a context with log.WithFields / log.Collect, or observability.WithSpanAttributes, and the values land on the log lines and on every span — including spans the framework starts on your behalf, which you never get a handle on. Metrics stay deliberately closed (unbounded labels are how cardinality blows up); when you need a metric of your own, build one with otel.Meter(...).
• No bespoke observability API to learn. It is the framework's log package and OpenTelemetry itself, so everything you already know about OTLP, collectors and backends still applies.

Dependency Injection, the Go Way

No reflection magic, no @Autowired annotations, no XML configuration. Every dependency is declared explicitly through constructor parameters and wired by type automatically:

gs.Provide(func(db *gorm.DB) *UserService {
    return &UserService{db: db}
})

Declare what you need, expose what you provide — nothing more.

Unified Runtime Model: Runners & Servers

Go-Spring distills all service patterns into two abstractions:

• Runner — A one-shot execution unit (scheduled tasks, batch processing, startup-only logic). The container collects all Runners and executes them in configured order.
• Server — A long-lived service (HTTP, gRPC, Thrift, WebSocket…). The container handles ListenAndServe and graceful shutdown; ReadySignal notifies when the service is ready.

No manual signal handling, no goroutine lifecycle management — the framework has you covered.

Built-in Enterprise Infrastructure