たった1人のAPI開発 BEAR.Sundayで解決した課題たち / PHPerKaigi2019_TrackB_1445

社内ベンチャーやスタートアップでは少ない人的リソースで高速にプロダクトを開発していくのが重要です

しかしながら、大きなピボットや急な仕様変更の可能性も高く、こういった状況でのAPI開発は様々な課題があらわれます

- 大きなピボットや急な仕様変更の可能性を踏まえて、どういう設計にするべきか
- アプリエンジニアとスムーズに連携するにはどうすればいいのか
- なにを大事にして、なにを後回しにするのか

このセッションでは上記の課題にどういう解決策を考え、BEAR.Sundayでどういったかたちで解決していったのか

そして、少し珍しいフレームワークであるBEAR.Sundayでの実務例をご紹介いたします

Transcript

1. たった1⼈のAPI開発
   BEAR.Sundayで解決した課題たち
   PHPerKaigi2019
   

   View Slide

2. ⻫藤 裕気(さいとう ひろき)
   Radiotalk株式会社
   @gamu1012
   Radiotalkのサーバーサイド
   

   View Slide

3. View Slide

4. ワンタップで配信
   Apple Podcastsへ配信
   

   View Slide

5. 時間 少
   変化 ⼤
   ⼈もお⾦もすくない
   新規事業の悩み
   

   View Slide

6. 悩み
   どういう設計にするべきか
   

   View Slide

7. 設計に銀の弾丸はない
   

   View Slide

8. 設計にあるもの

   

   ⽬指すべき理想
   制約
   

   View Slide

9. 理想とは？
   - 開発速度がはやい！
   - パフォーマンスがよい
   - テストのカバレッジ100%
   - お⾦もかからない
   

   View Slide

10. 理想とは？
    - 開発速度がはやい！
    - パフォーマンスがよい
    - テストのカバレッジ100%
    - お⾦もかからない
    理想をすべて実現する
    ことはできない
    

    View Slide

11. 制約とは？
    - 時間は有限
    - お⾦も有限
    - エンジニアの⼈数は増えない
    - 個⼈の経験や能⼒
    

    View Slide

12. Radiotalkではどうしたか
    

    View Slide

13. APIのフルリニューアル
    実現すること
    

    View Slide

14. Radiotalkの理想
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

15. Radiotalkの制約
    - 時間は有限
    - サーバーサイド1⼈
    - 運⽤も⼤事
    - WEB, ツールも開発
    - PHPがメイン
    - リニューアル
    - 他の⼈にも理解しやすく
    - ヤバい旧API
    - ヤバい旧DB
    - オンプレ
    - インフラの移⾏予定あり
    - ストリーミング再⽣
    - 12分の⾳声を扱う
    

    View Slide

16. 選択1
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

17. 選択2
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

18. 選択3
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

19. 選択4
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

20. 理想を実現させていく
    

    View Slide

21. PHPに関連のある理想
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

22. PHPに関連のある理想
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

23. 開発速度と変化に備えて
    インフラ, DBの変更に備えて
    - 密結合ではなく疎結合に
    - 1つのクラスをシンプルに
    - interfaceでつなぐ
    変更、追加しやすいことにも繋がる
    

    View Slide

24. なぜBEAR.Sunday？
    インフラ, DBの変更に備えて
    - 密結合ではなく疎結合に
    - 1つのクラスをシンプルに
    - interfaceでつなぐ
    変更、追加しやすいことにも繋がる
    適したフレームワーク？
    

    View Slide

25. http://bearsunday.github.io/index.html
    

    View Slide

26. BEAR.Sunday
    - リソース指向のフレームワーク
    - Ray.Di
    - Ray.Aop
    - BEAR.Resource
    

    View Slide

27. なぜBEAR.Sunday？
    - 強⼒なDI
    - AOPを標準サポート
    - json-schemaとApi.Doc
    

    View Slide

28. Resource
    Repository
    Service
    2層レイヤー
    

    View Slide

29. リソース設計について
    

    View Slide

30. View Slide

31. ユーザーリソース
    トークリソース
    番組リソース
    

    View Slide

32. ユーザーリソース
    トークリソース
    番組リソース
    ショートカット
    

    View Slide

33. トークリソース
    

    View Slide

34. PHPに関連のある理想
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

35. プロダクトの
    開発速度をあげるには？
    

    View Slide

36. API
    iOS
    Android
    

    View Slide

37. API
    iOS
    Android
    endpoint
    

    View Slide

38. API
    iOS
    Android
    endpoint
    直列状態では遅い
    

    View Slide

39. モックで解決する
    

    View Slide

40. モックとは
    - 中の処理は未実装
    - レスポンスは本番同等の仮データ
    - APIが未実装でも

    クライアントの開発を進められる
    

    View Slide

41. どうやってモックつくるか
    - PHPの配列で実現
    - 開発速度を優先
    - エンドポイントの数を多くはない
    - 融通がきく
    

    View Slide

42. API
    iOS
    Android
    endpoint
    

    View Slide

43. API
    iOS
    Android
    Mock
    

    View Slide

44. API
    iOS
    Android
    Mock
    開発速度UP!
    

    View Slide

45. API
    iOS
    Android
    endpoint
    endpoint
    

    View Slide

46. API
    iOS
    Android
    endpoint
    endpoint
    コミュニケーションコスト
    

    View Slide

47. APIドキュメントで解決
    

    View Slide

48. APIドキュメントで解決
    APIドキュメントは腐る
    

    View Slide

49. API ===
    ドキュメントの整合性
    

    View Slide

50. json-schemaとApi.Doc
    

    View Slide

51. json-schemaとは
    データ構造を記述、検証するためのツール
    jsonを検証するjson
    記述も検証もできる
    

    View Slide

52. http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
    

    View Slide

53. http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
    

    View Slide

54. Api.Doc
    

    View Slide

55. http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
    

    View Slide

56. https://bearsunday.github.io/tutorial2/
    

    View Slide

57. http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
    

    View Slide

58. https://bearsunday.github.io/tutorial2/rels/ticket.html
    

    View Slide

59. http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
    

    View Slide

60. API ===
    ドキュメントの整合性
    

    View Slide

61. API
    iOS
    Android
    endpoint
    endpoint
    

    View Slide

62. API
    iOS
    Android
    

    View Slide

63. API
    iOS
    Android
    開発速度UP!
    

    View Slide

64. 実装のまとめ
    - BEAR.Sunday
    - 2層のレイヤー構造
    - モック
    - json_schemaとApi.Doc
    

    View Slide

65. 振り返り
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

66. 改善点
    - 開発速度
    - インフラの変更につよい
    - DBの変更につよい
    - 低コスト
    - 変更、追加しやすい
    - パフォーマンスがよい
    - 通信量がすくない
    - ストリーミング再⽣
    - 他の⼈にも理解しやすく
    

    View Slide

67. Resource
    Repository
    Service
    2層レイヤー
    array[]
    

    View Slide

68. Resource
    Repository
    Service
    2層レイヤー
    array[]
    境界が不明瞭
    理解しづらい
    

    View Slide

69. 理想と制約
    ↓
    選択
    ↓
    振り返り
    

    View Slide

70. 理想と制約
    ↓
    選択
    ↓
    振り返り
    

    View Slide

71. プロダクトを
    作って終わりの時代ではない
    

    View Slide

72. 銀の弾丸を求めるのではなく
    理想と制約のなかで
    振り返りを続ける
    

    View Slide