Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
architecture of API server with golang
Search
mtskhs
May 28, 2018
Technology
4
820
architecture of API server with golang
Gopher道場#1 LT大会での発表資料です。
golamgによるAPIサーバー設計について検討してみました
mtskhs
May 28, 2018
Tweet
Share
More Decks by mtskhs
See All by mtskhs
EMがマジ価値を届けきるために考え行動したこと / Engineering Manager's thoughts and actions to deliver outcome
matsu0228
0
7.5k
Cloud Firestore With Go
matsu0228
0
920
Goとの歩み / History with Go
matsu0228
0
120
ReactNativeにおけるパフォーマンスチューニング/ Performance tuning in ReactNative
matsu0228
2
1.5k
スタートアップチームで学んだエンジニアの心構え / The attitude of the engineer who learned from the start-up team
matsu0228
1
1.7k
Goにおける API Client実装パターン / API Client implementation pattern in Go
matsu0228
7
8.3k
expo開発におけるCI/CD / CICD on development of expo
matsu0228
0
870
SpoLiveの爆速開発を支えるGAE/Goノウハウ / Practice of GAE&Go supporting SpoLive super fast development
matsu0228
1
240
Report of AgileTestingDays2018
matsu0228
0
540
Other Decks in Technology
See All in Technology
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
180
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
180
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
690
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
140
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
3
460
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
300
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
950
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.2k
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
120
Witchcraft for Memory
pocke
1
270
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
100
第9回情シス転職ミートアップ_テックタッチ株式会社
forester3003
0
220
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
What's in a price? How to price your products and services
michaelherold
246
12k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The World Runs on Bad Software
bkeepers
PRO
69
11k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Embracing the Ebb and Flow
colly
86
4.7k
Transcript
golangにおける APIアーキテクチャ設計 2018/5/28 @ gopher dojo LT Hisayuki Matsuki
自己紹介 松木 久幸 https://github.com/matsu0228 2 Server Side Engineer Python/Django Ruby
on Rails
What’s this? • Agenda 1. アーキテクチャ設計 2. golangで書いてみた 3. 課題点/疑問点
• 話すこと ◦ 概念的な話 ◦ packageの分け方 / interface ◦ サンプルコード(https://github.com/matsu0228/go_sandbox/tree/master/cleanArch) • 話さないこと ◦ どのようなFramework/Libraryを使うか ◦ 例:database接続には◦◦を使う 3
1-1.APIアーキテクチャ設計 • ある程度の規模のAPIサーバーをgolangで構築する ◦ GET /product/1795, POST /product/new ◦ GET
/campaign/5235 ◦ … • 要件 ◦ 修正時の影響範囲が限定的 かつ ◦ テストしやすい(databaseまわりなど) 4
1-2.Clean Architecture • 依存関係は一方方向(外から内側) • 上記に矛盾が発生しないよう、DIP(依存関係逆転の原則) ◦ Go: IFを活用 原文:
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html 5
2-1. レイヤー • Entity ◦ structを定義 • Usecase ◦ ビジネスロジックを定義
◦ <= IF:product.repository • Repository ◦ database操作を定義 ◦ <= database/sql (ref: sqlx) • HttpDeliver ◦ webサーバーを定義 ◦ <= IF:product.usecase 6
2-2. レイヤー:Entity • Entity ◦ structを定義 7
2-3. レイヤー:Repository • Repository ◦ database操作を定義 ◦ <= database/sql (ref:
sqlx) 8
2-4. レイヤー:Usecase • Usecase ◦ ビジネスロジックを定義 ◦ <= IF:product.repository 9
2-5. レイヤー:Usecase • 矛盾が発生しないよう、DIP(依存関係逆転の原則) 10
2-6. ディレクトリ構成 • 1st dir: エンドポイント種別 ◦ campaign, product, ...
,common • 2nd dir: layer ◦ -> 影響を限定的に 11
2-7. Usecaseのテスト • DatabaseをMockで差し替えて、ビジネスロジックのテストがし やすい ◦ <= IF:product.repository 12
3.課題点/疑問点 • そもそも1プロセスで、複数APIエンドポイント提供する? • 小規模なAPIでは、複雑なコードになりデメリットも大きそう(慣 れの問題?) ◦ 修正ごとに、IFを調整したり ◦ 配置場所が悪いと拡張性が悪くなりそうだったり
13
まとめ • ある程度の規模のAPIサーバーを、golangで構築する際の設計 について検討 ◦ 具体的なサンプルコードを基に、概要を説明 ◦ サンプルコード(https://github.com/matsu0228/go_sandbox/tree/master/cleanArch) • golangにおけるinterfaceの利用例を提示
• このLTをきっかけに、アーキテクチャ設計について知見を深め られればと 14