$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

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

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

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

hiroki.saito

March 30, 2019
Tweet

More Decks by hiroki.saito

Other Decks in Technology

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