architecture of API server with golang

Gopher道場#1 LT大会での発表資料です。
golamgによるAPIサーバー設計について検討してみました

Transcript

1. golangにおける APIアーキテクチャ設計 2018/5/28 @ gopher dojo LT 　 Hisayuki Matsuki
2. 自己紹介 松木 久幸 https://github.com/matsu0228 2 Server Side Engineer Python/Django Ruby on Rails
3. What’s this? • Agenda 1. アーキテクチャ設計 2. golangで書いてみた 3. 課題点/疑問点 • 話すこと ◦ 概念的な話 ◦ packageの分け方 / interface ◦ サンプルコード（https://github.com/matsu0228/go_sandbox/tree/master/cleanArch） • 話さないこと ◦ どのようなFramework/Libraryを使うか ◦ 例：database接続には◦◦を使う 3
4. 1-1.APIアーキテクチャ設計 • ある程度の規模のAPIサーバーをgolangで構築する ◦ GET /product/1795, POST /product/new ◦ GET /campaign/5235 ◦ … • 要件 ◦ 修正時の影響範囲が限定的 　かつ ◦ テストしやすい（databaseまわりなど） 4
5. 1-2.Clean Architecture • 依存関係は一方方向（外から内側） • 上記に矛盾が発生しないよう、DIP(依存関係逆転の原則) ◦ Go: IFを活用 原文: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html 5
6. 2-1. レイヤー • Entity ◦ structを定義 • Usecase ◦ ビジネスロジックを定義 ◦ <= IF:product.repository • Repository ◦ database操作を定義 ◦ <= database/sql (ref: sqlx) • HttpDeliver ◦ webサーバーを定義 ◦ <= IF:product.usecase 6
7. 2-2. レイヤー：Entity • Entity ◦ structを定義 7
8. 2-3. レイヤー：Repository • Repository ◦ database操作を定義 ◦ <= database/sql (ref: sqlx) 8
9. 2-4. レイヤー：Usecase • Usecase ◦ ビジネスロジックを定義 ◦ <= IF:product.repository 9
10. 2-5. レイヤー：Usecase • 矛盾が発生しないよう、DIP(依存関係逆転の原則) 10
11. 2-6. ディレクトリ構成 • 1st dir: エンドポイント種別 ◦ campaign, product, ... ,common • 2nd dir: layer ◦ -> 影響を限定的に 11
12. 2-7. Usecaseのテスト • DatabaseをMockで差し替えて、ビジネスロジックのテストがし やすい ◦ <= IF:product.repository 12
13. 3.課題点/疑問点 • そもそも１プロセスで、複数APIエンドポイント提供する？ • 小規模なAPIでは、複雑なコードになりデメリットも大きそう（慣 れの問題？） ◦ 修正ごとに、IFを調整したり ◦ 配置場所が悪いと拡張性が悪くなりそうだったり 13
14. まとめ • ある程度の規模のAPIサーバーを、golangで構築する際の設計 について検討 ◦ 具体的なサンプルコードを基に、概要を説明 ◦ サンプルコード（https://github.com/matsu0228/go_sandbox/tree/master/cleanArch） • golangにおけるinterfaceの利用例を提示 • このLTをきっかけに、アーキテクチャ設計について知見を深め られればと 14