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

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

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

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

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

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

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

87c08c5c7a07ff5aab32b1f84dc6ccb0?s=128

charlie@gamu1012

March 30, 2019
Tweet

Transcript

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

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

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

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

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

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

  8. 設計にあるもの
 
 ⽬指すべき理想 制約

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

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

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

  12. Radiotalkではどうしたか

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

  14. Radiotalkの理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト -

    変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
  15. Radiotalkの制約 - 時間は有限 - サーバーサイド1⼈ - 運⽤も⼤事 - WEB, ツールも開発

    - PHPがメイン - リニューアル - 他の⼈にも理解しやすく - ヤバい旧API - ヤバい旧DB - オンプレ - インフラの移⾏予定あり - ストリーミング再⽣ - 12分の⾳声を扱う
  16. 選択1 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト -

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

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

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

    変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
  20. 理想を実現させていく

  21. PHPに関連のある理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト -

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

    変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
  23. 開発速度と変化に備えて インフラ, DBの変更に備えて - 密結合ではなく疎結合に - 1つのクラスをシンプルに - interfaceでつなぐ 変更、追加しやすいことにも繋がる

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

    適したフレームワーク?
  25. http://bearsunday.github.io/index.html

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

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

  28. Resource Repository Service 2層レイヤー

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

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

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

  33. トークリソース

  34. PHPに関連のある理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト -

    変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
  35. プロダクトの 開発速度をあげるには?

  36. API iOS Android

  37. API iOS Android endpoint

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

  39. モックで解決する

  40. モックとは - 中の処理は未実装 - レスポンスは本番同等の仮データ - APIが未実装でも
 クライアントの開発を進められる

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

  42. API iOS Android endpoint

  43. API iOS Android Mock

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

  45. API iOS Android endpoint endpoint

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

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

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

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

  50. json-schemaとApi.Doc

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

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

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

  54. Api.Doc

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

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

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

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

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

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

  61. API iOS Android endpoint endpoint

  62. API iOS Android

  63. API iOS Android 開発速度UP!

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

  65. 振り返り - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト -

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

    変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
  67. Resource Repository Service 2層レイヤー array[]

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

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

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

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

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