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
770
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
2.8k
Cloud Firestore With Go
matsu0228
0
830
Goとの歩み / History with Go
matsu0228
0
110
ReactNativeにおけるパフォーマンスチューニング/ Performance tuning in ReactNative
matsu0228
2
1.4k
スタートアップチームで学んだエンジニアの心構え / The attitude of the engineer who learned from the start-up team
matsu0228
1
1.6k
Goにおける API Client実装パターン / API Client implementation pattern in Go
matsu0228
7
7.6k
expo開発におけるCI/CD / CICD on development of expo
matsu0228
0
790
SpoLiveの爆速開発を支えるGAE/Goノウハウ / Practice of GAE&Go supporting SpoLive super fast development
matsu0228
1
220
Report of AgileTestingDays2018
matsu0228
0
490
Other Decks in Technology
See All in Technology
SageMaker学習のツボ / The Key Points of Learning SageMaker
cmhiranofumio
0
270
管理画面とユーザー機能の調和を取り戻す!~クエリパフォーマンス改善の成功物語~ / Restore harmony between administrative and user functions!
minisera
1
200
不要なリソースを自動で定期的に整理する方法 ~Sandboxアカウントのコストを削減しよう!~
amixedcolor
4
230
マルチテナントのサービスインフラに大きなテナントを受け入れるまで
7474
0
560
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
130
入社半年(合計1年)でGoogle Cloud 認定を全冠した秘訣🤫
risatube
1
270
ReSTIRの数理と実装 (rtcamp10)
yumcyawiz
1
450
プロダクト開発の貢献をアピールするための目標設計や認知活動 / Goal design and recognition activities to promote product development contributions.
oomatomo
5
1k
Road to Single Activity Uncovered
yurihondo
0
110
20241015 Toranomon Tech Hub#1 Service Catalog使ってみた
hiashisan
0
210
LLMOps : ΔMLOps
shuntaito
6
1.1k
複数の外部サービスデータの統合と変換を実現する Railsのインポートアーキテクチャ / Rails import architecture for integration and transformation of multiple external service data
aiandrox
0
200
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
Building Applications with DynamoDB
mza
90
6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
46
4.9k
RailsConf 2023
tenderlove
28
860
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.6k
GitHub's CSS Performance
jonrohan
1030
450k
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