RedoclyでOpenAPIをタグ分割する方法

結論:RedoclyでOpenAPI Specをタグで分割できる Redocly CLIのfilter-in/filter-outデコレーターを使えば、1つのOpenAPI定義を複数のドキュメントに分割できる。 公開API用と管理API用でSwagger UIを分けたい場合など、タグベースでAPI仕様を分離できる。 背景:なぜ分割が必要か 単一のGo APIで複数のクライアント向けにエンドポイントを提供する場合、全エンドポイントを1つのSwagger UIに表示すると見づらい。 例: 公開API: ユーザー機能、コンテンツ表示 管理API: データ管理、レポート取得、設定変更 → それぞれ専用のSwagger UIを生成したい 解決方法:Redocly CLI + filter デコレーター 1. swagでOpenAPI定義を生成 swag: @echo "==> Running swag init" >&2 @swag init -g cmd/your-api/main.go -o docs @npx -y @redocly/cli@latest bundle docs/swagger.yaml --config docs/redocly-public.yaml -o docs/swagger_public.yaml @npx -y @redocly/cli@latest bundle docs/swagger.yaml --config docs/redocly-admin.yaml -o docs/swagger_admin.yaml && \ sed -i -e 's,API for Public,API for Admin,g' docs/swagger_admin.yaml 2. 公開API用設定:管理タグを除外 docs/redocly-public.yaml:...

2026-01-17 ·  2026-01-17 · 1 分 · 156 文字

Go言語omitemptyの罠:falseが保存できない

結論:omitemptyは便利だが罠がある omitemptyタグは空値を省略できて便利だが、falseや0が保存できなくなる罠がある。 特にboolean型で**「false」と「未設定」を区別したい場合は要注意**だ。 omitemptyとは 空値の場合にフィールドを省略するタグ。JSON/Firestoreへの保存時にデータサイズを削減できる。 type User struct { Name string `json:"name"` Email string `json:"email,omitempty"` // 空なら省略 } ⚠️ 最大の罠:「空」とみなされる値 以下の値は「空」として扱われ、omitempty付きフィールドから消える: 型 空とみなされる値 保存できない値の例 真偽値 false ❌ falseが保存不可 数値 0 ❌ 0が保存不可 文字列 "" ❌ 空文字列が保存不可 スライス/マップ nil または長さ0 ❌ 空配列が保存不可 ポインタ nil - 時刻 time.Timeのゼロ値 - 実例:boolean型の罠 問題のあるコード type Config struct { EnableFeature bool `firestore:"enableFeature,omitempty"` } config := Config{EnableFeature: false} // ❌ Firestoreに保存されない! // "enableFeature"フィールド自体が消える これでは「false」と「未設定」が区別できない。 解決策:ポインタ型を使う type Config struct { EnableFeature *bool `firestore:"enableFeature,omitempty"` } // パターン1: 未設定 config := Config{EnableFeature: nil} // → フィールド省略(未設定として扱える) // パターン2: 明示的にfalse falseValue := false config := Config{EnableFeature: &falseValue} // → ✅ falseとして保存される // パターン3: true trueValue := true config := Config{EnableFeature: &trueValue} // → ✅ trueとして保存される 動作比較 omitemptyあり type User struct { Name string `json:"name"` Age int `json:"age,omitempty"` Active bool `json:"active,omitempty"` } user := User{Name: "Alice", Age: 0, Active: false} // JSON: {"name":"Alice"} // ❌ Age=0 と Active=false は消える omitemptyなし user := User{Name: "Alice", Age: 0, Active: false} // JSON: {"name":"Alice","age":0,"active":false} // ✅ 0 と false もちゃんと保存される Firestore/JSONでの使い分け データ削減を優先する場合 Email string `json:"email,omitempty"` // 未入力のメールアドレスは保存しなくていい 値の区別が必要な場合 // boolean型: falseと未設定を区別したい IsAdmin *bool `firestore:"isAdmin,omitempty"` // 数値型: 0と未設定を区別したい Score *int `firestore:"score,omitempty"` まとめ omitemptyは空値を省略してデータサイズを削減できる false、0、空文字列は「空」扱いで消える(最大の罠) 値の区別が必要ならポインタ型を使う JSON/Firestoreどちらでも同じ仕組みで動作 Some illustrations on this site, including the Go Gopher, are by Renée French and licensed under CC BY 4....

2025-10-27 ·  2025-10-27 · 1 分 · 209 文字

コンテナ内でのみ golangci-lint 実行時に 'error obtaining VCS status: exit status 128' エラーが発生する問題

問題 golangci-lint をコンテナ内で実施すると以下エラーが発生した コンテナ内でのみ発生して、ホストで実行すると発生しなかった WARN [runner] Can't process results by diff processor: can't prepare diff by revgrep: no version control repository found cmd/main.go:1: : error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. (typecheck) 原因 golangci-lint は git の情報を取得しようとするが、コンテナ内の 作業ディレクトリが git の安全なディレクトリとして登録されていないために発生する 解決方法 以下 .gitconfig を作成して、compose.yaml で /root/.gitconfig:ro でマウントした [safe] directory = /work # コンテナ内の作業ディレクトリを指定 directory = /work/api # コンテナ内の作業ディレクトリを指定

2025-09-17 ·  2025-09-17 · 1 分 · 64 文字

GOで 構造体に定義したメソッドと埋め込みされたメソッドが同じシグニチャで無限ループに遭遇した

GOで 構造体に定義したメソッドと埋め込みされたメソッドが同じシグニチャで無限ループに遭遇した 以下実装で発生していた type SampleService struct { repository.SampleRepositoryHandler } func (s *SampleService) TargetFunction(ctx context.Context, sampleID, exampleID string) error { err := s.TargetFunction(ctx, sampleID, exampleID) if err != nil { // ... } } それまで異なる名前だったので、メソッド名変更を実施したタイミングで発生した為、気づかなかった ポイント 構造体埋め込み(匿名フィールド)は、委譲(delegation)として機能する 埋め込んだ型のメソッドを、親構造体のメソッドとして呼び出せる s.TargetFunction は SampleService のメソッドと、埋め込んだ SampleRepositoryHandler のメソッド両方を持つ 名前が重複している場合は、親構造体のメソッドが優先される 解決策 埋め込みで呼べたとしても、明示的に記載すべき

2025-08-27 ·  2025-09-17 · 1 分 · 46 文字

Cloud Function から IAM認証で CloudSQL(PostgreSQL) へ接続する

はじめに クラウド環境でのデータベース管理において、セキュリティは日々進化する脅威への対応が求められる重要課題です。特に、以下の課題が顕在化しています: 従来の認証情報(パスワード)の漏洩リスク 認証情報のローテーション管理の煩雑さ アプリケーション展開時の認証情報受け渡しの安全性確保 これらの課題に対し、IAM認証を活用することで、より強固でかつ運用負荷の少ないセキュリティ体制を実現できます。IAM認証のメリットは以下の通りです: 一時的な認証トークンの利用による漏洩リスクの低減 クラウドプロバイダーの統合認証基盤との連携による管理の一元化 きめ細かなアクセス制御とアクセスログの監査対応 本ガイドでは、Cloud FunctionsからCloudSQL(PostgreSQL)へIAM認証で接続する実践的な手順を解説します。この設定により、セキュアかつスケーラブルなデータベースアクセス環境を構築できます。 Cloud Function から CloudSQL(PostgreSQL) へ IAM 認証で接続するために必要な手順 Cloud Function 用 Service Account に必要な権限を付与 PGUSER の作成(IAM認証用) データベースへの権限付与 Cloud Function の実装 Service Account での Cloud Function のデプロイ 具体的な設定手順 1. Cloud Function 用 Service Account に必要な権限を付与 以下の権限が必要: Cloud SQL インスタンス ユーザー Cloud SQL クライアント 今回はコンソールから設定したが、以下のコマンドで設定も可能: gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.instanceUser" gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.client" 2. PGUSER の作成 IAM認証用のユーザーを作成する。...

2025-01-29 ·  2025-01-30 · 3 分 · 515 文字