architecture of API server with golang

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