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

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

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

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

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

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

Transcript

1. たった1⼈のAPI開発 BEAR.Sundayで解決した課題たち PHPerKaigi2019
2. ⻫藤 裕気(さいとう ひろき) Radiotalk株式会社 @gamu1012 Radiotalkのサーバーサイド
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. リソース設計について
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. 銀の弾丸を求めるのではなく 理想と制約のなかで 振り返りを続ける