Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
OpenAPI を用いた GoのAPIサーバー の開発自動化
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ysakura_
December 06, 2021
Technology
98
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
OpenAPI を用いた GoのAPIサーバー の開発自動化
マネーフォワードのPublic API開発において、OpenAPIを用いてGoのAPIサーバー構築を効率化しました。
利用シーン/技術選定/使ってみての長所短所を記載しています。
ysakura_
December 06, 2021
More Decks by ysakura_
See All by ysakura_
Goでの設定情報管理に苦労した話
ysakura_
0
430
マネーフォワードにおけるGoとマイクロサービスの活用事例
ysakura_
0
620
Other Decks in Technology
See All in Technology
DevelopersIO 2026 知識の地図を描く ─ オントロジーとは何か?
ishikawa_satoru
1
1.7k
"優秀な誰か"の下位互換にならないために
yut0naga1_fa
1
1.8k
Webの常識が通じないHTMLメールのダークモード
teamlab
PRO
0
130
Active Record Connection Adaptersにおける長年の課題に再び取り組む
yahonda
0
200
SAENM ~Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録!~
terapyon
0
120
DWH の限界突破! AI エージェント向け爆速リアルタイムデータ基盤 ClickHouse
jozono
1
490
触りたくないデータに、どう触るか AI時代のRBACアクセスガバナンス
ivry_presentationmaterials
0
270
パスキーの自動テストはどこまでいけるのか
teamlab
PRO
0
280
How to Design Configuration for Rails Applications
willnet
1
830
Benchmarking Disaggregated Serving on vLLM + Dynamo with a Real Coding-Agent Workload
nttcom
1
200
PagerDuty Tech Hub-鳴らすけれど、人は動かない
ezaki
0
180
CTO Night|NotionのAIエージェントとFDE
kzkhykw1991
0
220
Featured
See All Featured
Joys of Absence: A Defence of Solitary Play
codingconduct
1
550
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
Practical Orchestrator
shlominoach
192
12k
The Pragmatic Product Professional
lauravandoore
37
7.5k
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
940
Site-Speed That Sticks
csswizardry
13
1.6k
Documentation Writing (for coders)
carmenintech
77
5.6k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
59k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.2k
BBQ
matthewcrist
90
10k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Transcript
OpenAPIを用いて、GoのAPIサーバー構築を効率化した話
自己紹介
• 櫻 勇人(さくら ゆうと) ◦ Twitter: ysakura_ ◦ Go歴は3年ほど •
株式会社マネーフォワード @ 京都開発拠点 ◦ サーバーサイドエンジニア ▪ toB領域を主に担当 ◦ これまで ▪ Go製のマイクロサービスの開発運用 ◦ 最近 ▪ Public APIの開発推進 ▪ OAuth 2.0の認可基盤の開発 自己紹介
• MFでのAPI開発 • OpenAPIを採用した理由 • 利用したライブラリの紹介 • MFでの利用シーン • ライブラリの良かった点
/ 辛かった点 • 結論 今日話す事
• Public APIを絶賛開発中 ◦ 外部のサービスとの連携性向上が目的 ◦ Goのマイクロサービスがある所は GoでAPIを実装 • APIの基盤も構築中
◦ OAuth 2.0の認可基盤など ◦ こちらは別の機会に MFでのAPI開発
• OpenAPI ◦ 特定の開発言語に依存しない標準的な RESTful APIのインターフェース定義 ◦ 例 • スキーマ駆動開発をしたい
◦ 最初にスキーマ(API定義)を作り、それを元に開発を進めること ▪ 社外の人にAPIを使って貰うので、スキーマからスタートしたい ◦ API定義とサーバー実装がズレない様にしたい ▪ 外部に提供しているインターフェイスとずれると困る ▪ スキーマからGoのコードが自動生成される様にしたい • 利用事例が多いものを採用したい OpenAPIを採用した理由
https://github.com/deepmap/oapi-codegen • 使い方 利用したライブラリの紹介 go get github.com/deepmap/oapi-codegen/cmd/oapi-codegen oapi-codegen petstore-expanded.yaml >
petstore.gen.go
https://github.com/deepmap/oapi-codegen • 自動生成されるコードの例 ◦ OpenAPI ▪ petstore-expanded.yaml ◦ 型 ▪
petstore-types.gen.go ◦ handlerのベース実装 ▪ petstore-server.gen.go ◦ クライアント ▪ petstore-client.gen.go 利用したライブラリの紹介
MFでの利用シーン • APIサーバー ◦ handlerの自動生成 ◦ 型の自動生成 • テスト ◦
E2Eテストで自動生成されたクライアントを利用
• 型の自動生成 ◦ OpenAPIの型(Schema)が、Goの型として自動生成される ▪ petstore-types.gen.go ▪ OpenAPIとサーバー実装のズレが無くなった • handlerのベース実装の自動生成
◦ ルーターへのhandler登録 (生成例) ◦ パラメーターのパース (生成例) ◦ OpenAPIに基づいたhandlerのInterface(生成例) ▪ このInterfaceを守らないとBuildが失敗する • OpenAPIとサーバー実装のズレが無くなった oapi-codegenで良かった点
• クライアントの自動生成 ◦ E2Eテストで用いた ◦ 実装が減り、テスト作成がかなり楽になった ▪ HTTPリクエストの作成など ◦ 実装例
▪ 初期化 ▪ リクエスト oapi-codegenで良かった点
• Validatorが採用出来ず、自前でバリデーションを実装した ◦ OpenAPIを元にしたValidatorが提供されている(実装) ◦ APIサーバーから返るエラーは、自社のエラーフォーマットに沿う様にしたかった ▪ エラー時の文言/JSONを変更できないので、 oapi-codegenのValidatorは利用せず ◦
今思えば、oapi-codegenのエラーを受け取り、エラーハンドリングすべきだったかも ▪ 後続のmiddlewareで処理する様な形 • APIレスポンスのfieldの並び順が、OpenAPIの並び順と同じにならない ◦ curl等でデバッグする人向けに、重要な情報を上部に表示したかった ◦ OpenAPIの並びをソートして、 Goの構造体が作成される仕様 oapi-codegenで辛かった点
• リクエストとレスポンスで同じ型として扱いたいものが、別の型となってしまう ◦ ページネーションなど ▪ Cursor • Parameters ▪ NextCursor
• Schema ◦ これはもしかすると、 OpenAPIの使い方が悪いのかもしれない oapi-codegenで辛かった点
• スキーマ駆動開発は楽 ◦ OpenAPIを正とした開発の安心感は強い • deepmap/oapi-codegen オススメ ◦ handlerのロジック実装に集中する事が出来た 結論
We are hiring! Goを使って、ユーザーの課題を解決したいエンジニアを募集中です! カジュアル面談から是非