Spine - 韓国で作られた、魔法のないバックエンドWebフレームワーク

narubrown · 2026-01-18T23:03:16+09:00

Spineは、実行フローを隠さず明示的に表現するGoベースのバックエンドWebフレームワーク単一のPipelineが全体の実行順序を管理し、Controllerはビジネスロジックだけに集中メソッドシグネチャがそのままAPI契約であり、アノテーションや慣習ベースの自動化はないリクエストの順序がコード上で明確に見える初期の生産性よりも、長期的な保守性と実行フローの追跡しやすさに重点 EchoをHTTP Transportとして使用し、ORM非依存の設計によりBun/GORMなどを自由に選択可能 Spine 概要 Spineは、Webリクエストの実行フローを明示的に表現することを目標としたフレームワーク多くのフレームワークが利便性のために隠してしまう実行順序を、コード構造として固定する「リクエストがどこで始まり、誰が処理し、どの順序で実行されるのか」に明確に答えられる構造を志向設計原則魔法なしポリシー実行順序を知るコンポーネントはPipelineただ一つ「よしなにやってくれる」動作を最小化すべての拡張と実行は明示的に登録され、予測可能な順序を持つシグネチャベースの契約メソッドシグネチャがそのままAPI契約入力生成はArgumentResolver、出力処理はReturnValueHandlerが担当アノテーションベースのマッピング、慣習ベースの自動推論は禁止 Controllerの独立性 ControllerはHTTP/Transport型に依存しない path.*、query.*、httperr.* のような意味型のみを使用実行モデルは知らなくても、入力の出所は型で明示主な機能ルーティングとパラメータ Path Parameter対応（順序ベースのバインディング） Query Valuesユーティリティ（Int、String、Booleanのパース） Body DTOの自動バインディングレスポンス処理 ReturnValueHandlerによる struct -> JSON の自動変換 error -> HTTPステータスコードの自動マッピング httperr.NotFound、BadRequest など意味ベースのエラー型横断的関心事 Interceptor（PreHandle、PostHandle、AfterCompletion） CORS Interceptor内蔵コンストラクタベースのIoC Container アーキテクチャ Transport層を分離（現在はEcho、差し替え可能な設計） ORM非依存設計（Bun、GORMなどを自由に使用可能 ⚠️ 現在はBunのみ互換性確認済み）大規模環境での強み実行順序を把握する主体が一つだけなので、リクエストフロー追跡のコストを削減ロギング、トランザクション、セキュリティのような横断的関心事はPipelineにのみ配置されるため、適用箇所とタイミングを予測しやすい。初期の生産性を一部犠牲にしつつ、長期的に増大する複雑性を構造で吸収する戦略 Spineではないもの Spring/NestJSの代替ではない生産性最大化フレームワークではないアノテーションベース自動化フレームワークではない HTTP EngineやRouter中心のフレームワークではない Spineが助けを必要としているプロジェクト Spineはまだ完成したフレームワークではなく、意図的に多くの部分を未完成の状態で公開構造が十分に説明可能か、実行モデルが実際の問題をうまく表現できているかの検証が必要参加方法 GitHubで⭐️を付けてプロジェクトをウォッチする実際に使ってみて感じたことや疑問をIssueとして残す設計に対する批判、提案、質問をコメントで残す参考リンク Spineプロジェクト: https://github.com/NARUBROWN/spine Spine + Bun ORM User Demo: https://github.com/NARUBROWN/spine-user-demo

(na2ru2.me)

13 ポイント投稿者 narubrown 2026-01-18 | 2件のコメント | WhatsAppで共有

Spineは、実行フローを隠さず明示的に表現するGoベースのバックエンドWebフレームワーク
単一のPipelineが全体の実行順序を管理し、Controllerはビジネスロジックだけに集中
メソッドシグネチャがそのままAPI契約であり、アノテーションや慣習ベースの自動化はない
リクエストの順序がコード上で明確に見える
初期の生産性よりも、長期的な保守性と実行フローの追跡しやすさに重点
EchoをHTTP Transportとして使用し、ORM非依存の設計によりBun/GORMなどを自由に選択可能

Spine 概要

Spineは、Webリクエストの実行フローを明示的に表現することを目標としたフレームワーク
多くのフレームワークが利便性のために隠してしまう実行順序を、コード構造として固定する
「リクエストがどこで始まり、誰が処理し、どの順序で実行されるのか」に明確に答えられる構造を志向

設計原則

魔法なしポリシー

実行順序を知るコンポーネントはPipelineただ一つ
「よしなにやってくれる」動作を最小化
すべての拡張と実行は明示的に登録され、予測可能な順序を持つ

シグネチャベースの契約

メソッドシグネチャがそのままAPI契約
入力生成はArgumentResolver、出力処理はReturnValueHandlerが担当
アノテーションベースのマッピング、慣習ベースの自動推論は禁止

Controllerの独立性

ControllerはHTTP/Transport型に依存しない
path.*、query.*、httperr.* のような意味型のみを使用
実行モデルは知らなくても、入力の出所は型で明示

主な機能

ルーティングとパラメータ

Path Parameter対応（順序ベースのバインディング）
Query Valuesユーティリティ（Int、String、Booleanのパース）
Body DTOの自動バインディング

レスポンス処理

ReturnValueHandlerによる struct -> JSON の自動変換
error -> HTTPステータスコードの自動マッピング
httperr.NotFound、BadRequest など意味ベースのエラー型

横断的関心事

Interceptor（PreHandle、PostHandle、AfterCompletion）
CORS Interceptor内蔵
コンストラクタベースのIoC Container

アーキテクチャ

Transport層を分離（現在はEcho、差し替え可能な設計）
ORM非依存設計（Bun、GORMなどを自由に使用可能 ⚠️ 現在はBunのみ互換性確認済み）

大規模環境での強み

実行順序を把握する主体が一つだけなので、リクエストフロー追跡のコストを削減
ロギング、トランザクション、セキュリティのような横断的関心事はPipelineにのみ配置されるため、適用箇所とタイミングを予測しやすい。初期の生産性を一部犠牲にしつつ、長期的に増大する複雑性を構造で吸収する戦略

Spineではないもの

Spring/NestJSの代替ではない
生産性最大化フレームワークではない
アノテーションベース自動化フレームワークではない
HTTP EngineやRouter中心のフレームワークではない

Spineが助けを必要としているプロジェクト

Spineはまだ完成したフレームワークではなく、意図的に多くの部分を未完成の状態で公開
構造が十分に説明可能か、実行モデルが実際の問題をうまく表現できているかの検証が必要

参加方法

GitHubで⭐️を付けてプロジェクトをウォッチする
実際に使ってみて感じたことや疑問をIssueとして残す
設計に対する批判、提案、質問をコメントで残す

参考リンク

Spineプロジェクト: https://github.com/NARUBROWN/spine
Spine + Bun ORM User Demo: https://github.com/NARUBROWN/spine-user-demo

2件のコメント

bsh998 2026-01-20

AIの説明を少し修正して、もう少し自然な文章にしていただけると、信頼性が高まると思います。

narubrown 2026-01-20

こんにちは、フィードバック本当にありがとうございます。
AIっぽいというのは、GeekNews の投稿のことをおっしゃっていますか？

ここはもともとこういうふうに書くものだと思っていて ^^… 他の投稿もこうだったので、あえてこのように書きました。

https://spine.na2ru2.me/ko/
さらに、spine を学べるサイトも開設しました。
ご興味があればぜひ一緒にご覧ください。ありがとうございます。