{"id":46759959,"title":"Show HN: Spine – an execution-centric backend framework for Go","points":2,"user":"narubrown","time":1769385093,"time_ago":"4 days ago","type":"link","content":"

Hello Hacker News — greetings from South Korea \nI’m a backend engineer working primarily with Go, and I’d like to share a framework I’ve been building to solve a problem I’ve repeatedly encountered in production systems.

In my day-to-day work, our backend is built on top of Echo. Echo is fast and reliable as an HTTP transport, but its high level of freedom leaves architectural decisions almost entirely to individual developers. Over time, this led to a system where execution flow and responsibility boundaries varied depending on who last touched a feature. Maintenance became difficult not because the code was incorrect, but because how requests actually executed was no longer obvious.

I looked for a Go framework that could provide a clear execution model and structural constraints, similar to what Spring or NestJS offer. I couldn’t find one that fit. Moving to Spring or NestJS would also mean giving up some of Go’s strengths—simplicity, performance, and explicit control—so I decided to build one instead.

Spine is an execution-centric backend framework for Go.\nIt aims to provide enterprise-grade structure while deliberately avoiding hidden magic.

What Spine provides\n • An IoC container with explicit, constructor-based dependency injection\n • Interceptors with well-defined execution phases (before, after, completion)\n • First-class support for both HTTP requests and event-driven execution\n • No annotations, no implicit behavior, no convention-driven wiring

The core idea: execution first

The key difference is Spine’s execution model.

Every request—HTTP or event—flows through a single, explicit Pipeline.\nThe Pipeline is the only component that determines execution order.\nActual method calls are handled by a separate Invoker, keeping execution control and invocation strictly separated.

Because of this structure:\n • Execution order is explainable by reading the code\n • Cross-cutting concerns live in the execution flow, not inside controllers\n • Controllers express use cases only, not orchestration logic\n • You can understand request handling by looking at main.go

This design trades some convenience for clarity. In return, it offers stronger control as the system grows in size and complexity.

My goal with Spine isn’t just to add another framework to the Go ecosystem, but to start a conversation:\nHow much execution flow do modern web frameworks hide, and when does that become a maintenance cost?

The framework itself is currently written in Korean.\nIf English support or internationalization is important to you, feel free to open an issue—I plan to prioritize it based on community interest.

You can find more details, a basic HTTP example, and a simple Kafka-based MSA demo here:\nRepository: https://github.com/NARUBROWN/spine

Thanks for reading. I’d really appreciate your feedback.","url":"https://spine.na2ru2.me/en/","domain":"spine.na2ru2.me","comments":[],"comments_count":0}