Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
たった1⼈のAPI開発 BEAR.Sundayで解決した課題たち PHPerKaigi2019
Slide 2
Slide 2 text
⻫藤 裕気(さいとう ひろき) Radiotalk株式会社 @gamu1012 Radiotalkのサーバーサイド
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
ワンタップで配信 Apple Podcastsへ配信
Slide 5
Slide 5 text
時間 少 変化 ⼤ ⼈もお⾦もすくない 新規事業の悩み
Slide 6
Slide 6 text
悩み どういう設計にするべきか
Slide 7
Slide 7 text
設計に銀の弾丸はない
Slide 8
Slide 8 text
設計にあるもの ⽬指すべき理想 制約
Slide 9
Slide 9 text
理想とは? - 開発速度がはやい! - パフォーマンスがよい - テストのカバレッジ100% - お⾦もかからない
Slide 10
Slide 10 text
理想とは? - 開発速度がはやい! - パフォーマンスがよい - テストのカバレッジ100% - お⾦もかからない 理想をすべて実現する ことはできない
Slide 11
Slide 11 text
制約とは? - 時間は有限 - お⾦も有限 - エンジニアの⼈数は増えない - 個⼈の経験や能⼒
Slide 12
Slide 12 text
Radiotalkではどうしたか
Slide 13
Slide 13 text
APIのフルリニューアル 実現すること
Slide 14
Slide 14 text
Radiotalkの理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 15
Slide 15 text
Radiotalkの制約 - 時間は有限 - サーバーサイド1⼈ - 運⽤も⼤事 - WEB, ツールも開発 - PHPがメイン - リニューアル - 他の⼈にも理解しやすく - ヤバい旧API - ヤバい旧DB - オンプレ - インフラの移⾏予定あり - ストリーミング再⽣ - 12分の⾳声を扱う
Slide 16
Slide 16 text
選択1 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 17
Slide 17 text
選択2 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 18
Slide 18 text
選択3 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 19
Slide 19 text
選択4 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 20
Slide 20 text
理想を実現させていく
Slide 21
Slide 21 text
PHPに関連のある理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 22
Slide 22 text
PHPに関連のある理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 23
Slide 23 text
開発速度と変化に備えて インフラ, DBの変更に備えて - 密結合ではなく疎結合に - 1つのクラスをシンプルに - interfaceでつなぐ 変更、追加しやすいことにも繋がる
Slide 24
Slide 24 text
なぜBEAR.Sunday? インフラ, DBの変更に備えて - 密結合ではなく疎結合に - 1つのクラスをシンプルに - interfaceでつなぐ 変更、追加しやすいことにも繋がる 適したフレームワーク?
Slide 25
Slide 25 text
http://bearsunday.github.io/index.html
Slide 26
Slide 26 text
BEAR.Sunday - リソース指向のフレームワーク - Ray.Di - Ray.Aop - BEAR.Resource
Slide 27
Slide 27 text
なぜBEAR.Sunday? - 強⼒なDI - AOPを標準サポート - json-schemaとApi.Doc
Slide 28
Slide 28 text
Resource Repository Service 2層レイヤー
Slide 29
Slide 29 text
リソース設計について
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
ユーザーリソース トークリソース 番組リソース
Slide 32
Slide 32 text
ユーザーリソース トークリソース 番組リソース ショートカット
Slide 33
Slide 33 text
トークリソース
Slide 34
Slide 34 text
PHPに関連のある理想 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 35
Slide 35 text
プロダクトの 開発速度をあげるには?
Slide 36
Slide 36 text
API iOS Android
Slide 37
Slide 37 text
API iOS Android endpoint
Slide 38
Slide 38 text
API iOS Android endpoint 直列状態では遅い
Slide 39
Slide 39 text
モックで解決する
Slide 40
Slide 40 text
モックとは - 中の処理は未実装 - レスポンスは本番同等の仮データ - APIが未実装でも クライアントの開発を進められる
Slide 41
Slide 41 text
どうやってモックつくるか - PHPの配列で実現 - 開発速度を優先 - エンドポイントの数を多くはない - 融通がきく
Slide 42
Slide 42 text
API iOS Android endpoint
Slide 43
Slide 43 text
API iOS Android Mock
Slide 44
Slide 44 text
API iOS Android Mock 開発速度UP!
Slide 45
Slide 45 text
API iOS Android endpoint endpoint
Slide 46
Slide 46 text
API iOS Android endpoint endpoint コミュニケーションコスト
Slide 47
Slide 47 text
APIドキュメントで解決
Slide 48
Slide 48 text
APIドキュメントで解決 APIドキュメントは腐る
Slide 49
Slide 49 text
API === ドキュメントの整合性
Slide 50
Slide 50 text
json-schemaとApi.Doc
Slide 51
Slide 51 text
json-schemaとは データ構造を記述、検証するためのツール jsonを検証するjson 記述も検証もできる
Slide 52
Slide 52 text
http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
Slide 53
Slide 53 text
http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
Slide 54
Slide 54 text
Api.Doc
Slide 55
Slide 55 text
http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
Slide 56
Slide 56 text
https://bearsunday.github.io/tutorial2/
Slide 57
Slide 57 text
http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
Slide 58
Slide 58 text
https://bearsunday.github.io/tutorial2/rels/ticket.html
Slide 59
Slide 59 text
http://bearsunday.github.io/manuals/1.0/ja/tutorial2.html
Slide 60
Slide 60 text
API === ドキュメントの整合性
Slide 61
Slide 61 text
API iOS Android endpoint endpoint
Slide 62
Slide 62 text
API iOS Android
Slide 63
Slide 63 text
API iOS Android 開発速度UP!
Slide 64
Slide 64 text
実装のまとめ - BEAR.Sunday - 2層のレイヤー構造 - モック - json_schemaとApi.Doc
Slide 65
Slide 65 text
振り返り - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 66
Slide 66 text
改善点 - 開発速度 - インフラの変更につよい - DBの変更につよい - 低コスト - 変更、追加しやすい - パフォーマンスがよい - 通信量がすくない - ストリーミング再⽣ - 他の⼈にも理解しやすく
Slide 67
Slide 67 text
Resource Repository Service 2層レイヤー array[]
Slide 68
Slide 68 text
Resource Repository Service 2層レイヤー array[] 境界が不明瞭 理解しづらい
Slide 69
Slide 69 text
理想と制約 ↓ 選択 ↓ 振り返り
Slide 70
Slide 70 text
理想と制約 ↓ 選択 ↓ 振り返り
Slide 71
Slide 71 text
プロダクトを 作って終わりの時代ではない
Slide 72
Slide 72 text
銀の弾丸を求めるのではなく 理想と制約のなかで 振り返りを続ける