Pocochaにおけるフロントエンドの領域とアーキテクチャ変遷【DeNA TechCon 2021 Summer】/techcon2021summer-05

Pocochaの成長とともに、採用技術も幾度となく変化してきました。中でも流れの速いフロントエンド領域では、フレームワークの乗り換え・アーキテクチャの変更・インフラの移行と大きな変化を経てきています。

それぞれのフェーズにおいてどのような判断の元で次のステップへ移ったのか、そしてどのような反省が生まれたのか、その変遷についてご紹介いたします。

Transcript

1. Pocochaにおけるフロントエンドの領域と アーキテクチャ変遷 菰原 裕 1
2. 自己紹介 • 菰原 裕 / Yu Komohara • 2018年DeNA新卒入社 ◦ Pococha事業部 システム部 ◦ イベントチームでバックエンド開発 ◦ その後Webチームでフロントエンド開発 ▪ Rails, React, Next.js, ... 2
3. 今日お話すること 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史 フレームワーク移行 3. Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 4. 展望 3
4. 今日お話しないこと • フレームワークの基礎（Rails, Next.js） ◦ 一部機能の紹介はいたします • 使用ライブラリの詳細（React, Redux, etc...） • 実装パターン（Hooks, HOC, 各種 API, etc...） 4
5. 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史 フレームワーク移行 3. Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 4. 展望 5
6. Pocochaとは • 2017年にサービスが開始したライブ 配信アプリ • 配信をするライバーと、コメントやア イテムで応援するリスナーの双方向コ ミュニケーション • 様々な形式のイベントが行われている 6
7. Webの領域 7
8. Webの領域 • アプリ内WebView • Pococha Web版 • 公式サイト・その他Webページ（規約等） 8
9. Webの領域 • アプリ内WebView • Pococha Web版 • 公式サイト・その他Webページ （規約等） 9
10. Webの領域 • アプリ内WebView • Pococha Web版 • 公式サイト・その他Webページ （規約等） 10
11. Webの領域 • アプリ内WebView • Pococha Web版 • 公式サイト・その他Webページ （規約等） 11
12. なぜWebを使うのか？ 12
13. Webで実装する意味 • 企画の PDCA・仮説検証が回しやすい（主にWeb版） 13
14. Webで実装する意味 • 企画の PDCA・仮説検証が回しやすい（主にWeb版） ◦ 本番反映や取り下げが容易 14
15. Webで実装する意味 • 企画の PDCA・仮説検証が回しやすい（主にWeb版） ◦ 本番反映や取り下げが容易 ◦ ネイティブのリリースサイクルに影響されない （Pococha なら二週間に一回） 15
16. Webで実装する意味 • 企画の PDCA・仮説検証が回しやすい（主にWeb版） ◦ 本番反映や取り下げが容易 ◦ ネイティブのリリースサイクルに影響されない （Pococha なら二週間に一回） • iOS, Android の両方で WebView さえ用意してあげれ ばクロスプラットフォーム 16
17. Webで実装する意味 • 企画の PDCA・仮説検証が回しやすい（主にWeb版） ◦ 本番反映や取り下げが容易 ◦ ネイティブのリリースサイクルに影響されない （Pococha なら二週間に一回） • iOS, Android の両方で WebView さえ用意してあげれ ばクロスプラットフォーム • エンジニアリソースを有効活用できる 17
18. 以上が、Pocochaにおける Webフロントエンドの領域の話です 18
19. ここから、その変遷をお話いたします 19
20. 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史 フレームワーク移行 3. Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 4. 展望 20
21. 初期（2017/1〜2018/11） • Rails が API サーバと Web サーバの両方の役割を担う 21
22. 初期（2017/1〜2018/11） • Rails が API サーバと Web サーバの両方の役割を担う • 試行錯誤をしていた段階で、ページごと（イベントはイベントごと） にUIが異なり、マスターデータを元に動的にページを生成できない 22
23. 初期（2017/1〜2018/11） • Rails が API サーバと Web サーバの両方の役割を担う • 試行錯誤をしていた段階で、ページごと（イベントはイベントごと） にUIが異なり、マスターデータを元に動的にページを生成できない • ページ数が少ないので、なんとかコピペ運用で回せていた時期 23
24. 事業拡大に伴う課題 24
25. 事業拡大に伴う課題 • 自動化されても辛いコピペ運用 25
26. 事業拡大に伴う課題 • 自動化されても辛いコピペ運用 ◦ イベント数の増加 26
27. 事業拡大に伴う課題 • 自動化されても辛いコピペ運用 ◦ イベント数の増加 ◦ フォーマットも固まってきたので、ページを共通化したい 27
28. 事業拡大に伴う課題 • 自動化されても辛いコピペ運用 ◦ イベント数の増加 ◦ フォーマットも固まってきたので、ページを共通化したい • LP のような、フロントで完結するページを Rails で作るのは辛い 28
29. 事業拡大に伴う課題 • 自動化されても辛いコピペ運用 ◦ イベント数の増加 ◦ フォーマットも固まってきたので、ページを共通化したい • LP のような、フロントで完結するページを Rails で作るのは辛い • リッチな UI を JS でゴリゴリ書きたい 29
30. 新フレームワークへ移行しよう 30
31. 当時（2018年夏頃）検討された選択肢 31
32. 当時（2018年夏頃）検討された選択肢 • Angular • React + React Helmet • Vue + Nuxt.js • React + Next.js 32
33. 当時（2018年夏頃）検討された選択肢 • Angular ◦ 半年に一度の破壊的なメジャーアップデート • React + React Helmet • Vue + Nuxt.js • React + Next.js 33
34. 当時（2018年夏頃）検討された選択肢 • Angular ◦ 半年に一度の破壊的なメジャーアップデート • React + React Helmet ◦ webpack や Babel や Express を自前で入れて管理する必要がある • Vue + Nuxt.js • React + Next.js 34
35. 当時（2018年夏頃）検討された選択肢 • Angular ◦ 半年に一度の破壊的なメジャーアップデート • React + React Helmet ◦ webpack や Babel や Express を自前で入れて管理する必要がある • Vue + Nuxt.js ◦ SSR (後述)は出来るが、当時（Vue 2）ビューにロジックを含めたくなかった • React + Next.js 35
36. 当時（2018年夏頃）検討された選択肢 • Angular ◦ 半年に一度の破壊的なメジャーアップデート • React + React Helmet ◦ webpack や Babel や Express を自前で入れて管理する必要がある • Vue + Nuxt.js ◦ SSR (後述)は出来るが、当時（Vue 2）ビューにロジックを含めたくなかった • React + Next.js ◦ 自前でビルド周りやサーバを整備する必要がない。SSR が容易に行える 36
37. 移行ステップ • React + Next.js のプロジェクトを立ち上げる ◦ ページを作る ◦ 認証機構を実装する ◦ デプロイフローを整える • フロント側にデータを渡す仕組みを作る ◦ データフォーマットを定める（csv, yaml） ◦ API を Rails に生やす 37
38. React + Next.js に移行しました （2018/12 運用開始） 38
39. 簡易構成図（〜2018/12） 39
40. 簡易構成図（2018/12〜） 40
41. 簡易構成図（2018/12〜） ※現在も Rails から Next.js へページを移行中 41
42. 事業拡大に伴う課題（再掲） • 自動化されても辛いコピペ運用 • LP のような、フロントで完結するページを Rails で作るのが辛い • リッチな UI を JS でゴリゴリ書きたい 42
43. 事業拡大に伴う課題（再掲） • 自動化されても辛いコピペ運用 ◦ API 側にマスターデータを保持してページに流し込む形式 • LP のような、フロントで完結するページを Rails で作るのが辛い • リッチな UI を JS でゴリゴリ書きたい 43
44. 事業拡大に伴う課題（再掲） • 自動化されても辛いコピペ運用 ◦ API 側にマスターデータを保持してページに流し込む形式 • LP のような、フロントで完結するページを Rails で作るのが辛い ◦ LP を Rails に載せる必要がなくなった • リッチな UI を JS でゴリゴリ書きたい 44
45. 事業拡大に伴う課題（再掲） • 自動化されても辛いコピペ運用 ◦ API 側にマスターデータを保持してページに流し込む形式 • LP のような、フロントで完結するページを Rails で作るのが辛い ◦ LP を Rails に載せる必要がなくなった • リッチな UI を JS でゴリゴリ書きたい ◦ Rails の制約がないので好きに書ける 45
46. すべて解決！！ 46
47. そんなことはなく 47
48. 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史 フレームワーク移行 3. Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 4. 展望 48
49. CSR と SSR 49
50. CSR(Client Side Rendering) 1. ユーザがリクエストを送る 2. サーバからのレスポンス後に JS がクライアント（ブラウザ）へダウ ンロードされる 3. クライアント側で JS が実行される 4. 実行が終わった段階でページが表示される 50
51. SSR(Server Side Rendering) 1. ユーザがリクエストを送る 2. リクエストが到達した段階で、サーバ側で JS が実行される 3. 初期表示用のページ（First View）をレンダリングして、レスポンス が返る 4. その後必要に応じてクライアント側でも JS が実行され、最終的な ページが表示される 51
52. SSR のメリット 52
53. SSR のメリット • UX 向上 ◦ 初回レンダリングがブラウザではなくサーバで行われるので、高速 ◦ ブラウザでの JS の実行を待たずに描画されるため、空白ページやインジ ケータが表示されない 53
54. SSR のメリット • UX 向上 ◦ 初回レンダリングがブラウザではなくサーバで行われるので、高速 ◦ ブラウザでの JS の実行を待たずに描画されるため、空白ページやインジ ケータが表示されない • SEO ◦ 必要な情報をサーバ側でレンダリングした上でレスポンスが返るので /users/[userId] のような動的なルーティングでも OGP を設定できる ◦ クローラに関しては、レンダリングのタイムラグ以外は問題ない 54
55. SSR のデメリット 55
56. SSR のデメリット • 自前で導入するのは難しい ◦ フレームワークに依存することになる 56
57. SSR のデメリット • 自前で導入するのは難しい ◦ フレームワークに依存することになる • コードが煩雑になる ◦ Next.js（当時は 9.1.6） では getInitialProps という SSR でも CSR で も呼ばれるライフサイクルがあり、Universal JS を意識する必要があっ た 57
58. SSR のデメリット • 自前で導入するのは難しい ◦ フレームワークに依存することになる • コードが煩雑になる ◦ Next.js（当時は 9.1.6） では getInitialProps という SSR でも CSR で も呼ばれるライフサイクルがあり、Universal JS を意識する必要があっ た ◦ SSR はサーバ側（Node 環境）で実行されシングルスレッドで動作し、シ ングルスレッドで固有の問題も生じうる 58
59. SSR をやめたい…… 59
60. そんな中 60
61. getStaticProps の登場 • Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に 実行されるライフサイクル 61
62. getStaticProps の登場 • Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に 実行されるライフサイクル • SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた 静的コンテンツが返るので、レスポンスが早い 62
63. getStaticProps の登場 • Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に 実行されるライフサイクル • SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた 静的コンテンツが返るので、レスポンスが早い • Next.js にも静的に書き出す機能や自動的に SSG される機構が存在したが、9.3 で専用のライフサイクルが登場した 63
64. getStaticProps の登場 • Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に 実行されるライフサイクル • SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた 静的コンテンツが返るので、レスポンスが早い • Next.js にも静的に書き出す機能や自動的に SSG される機構が存在したが、9.3 で専用のライフサイクルが登場した • 動的ページで SSG を実装するための getStaticPaths というライフサイクルも 同時に登場 64
65. getStaticProps の登場 • Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に 実行されるライフサイクル • SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた 静的コンテンツが返るので、レスポンスが早い • Next.js にも静的に書き出す機能や自動的に SSG される機構が存在したが、9.3 で専用のライフサイクルが登場した • 動的ページで SSG を実装するための getStaticPaths というライフサイクルも 同時に登場 • Vercel へのデプロイ時、条件を満たすページは自動で SSG を行って CDN へ展 開してくれるなど、SSG のサポートは強力 65
66. SSGの実装 • www.example.com/entries のような一 覧ページ 66
67. SSGの実装 • www.example.com/entries のような一 覧ページ • ビルド時に getStaticProps が実行さ れ、一覧情報が API から取得される 67
68. SSGの実装 • www.example.com/entries のような一 覧ページ • ビルド時に getStaticProps が実行さ れ、一覧情報が API から取得される • getStaticProps の return がコンポーネ ントへ渡され、APIで取得した情報を元に 事前にビルドされる 68
69. SSGの実装（動的ルーティング） • www.example.com/entries/[entryId] のような詳細ページ 69
70. SSGの実装（動的ルーティング） • www.example.com/entries/[entryId] のような詳細ページ • getStaticPaths で、事前にどの ID の ページについて SSG するかを指定する 70
71. SSGの実装（動的ルーティング） • www.example.com/entries/[entryId] のような詳細ページ • getStaticPaths で、事前にどの ID の ページについて SSG するかを指定する • それぞれのページについて、ページ内容を getStaticProps で API から取得する 71
72. SSGの実装（動的ルーティング） • www.example.com/entries/[entryId] のような詳細ページ • getStaticPaths で、事前にどの ID の ページについて SSG するかを指定する • それぞれのページについて、ページ内容を getStaticProps で API から取得する • getStaticProps の return がコンポーネ ントへ渡され、getStaticPaths で指定し た全てのパスについて事前ビルドが行われ る 72
73. 事前にビルドするページ数が 膨大だったら……？ 73
76. ISG(Incremental Static Generation) • getStaticProps 等と同じく Next.js 9.3（2020/3）で追加 • getStaticPaths で fallback を false 以外に指定した場合に有効化 • 事前ビルドしていないページへリクエストが到達した段階でインクリ メンタルに SSG を実行し、以後そのページへのリクエストには SSG されたコンテンツが返る 76
77. 一度 SSG されたページの内容が 変更されたら……？ 77
78. 一度 SSG されたページの内容が 変更されたら……？ 実際に、エラーページをキャッシュしてしまう障害を起こしたこともありました 78
79. ISR(Incremental Static Regeneration) • Next.js 9.5（2020/7）で追加 • getStaticProps の return で revalidate を指定した場合に有効化 • revalidate で指定した秒数の経過後、新しいリクエストが来たら、再度 SSG を実行す る（= キャッシュを更新する） 79
80. SSR → SSG + ISR 80
81. 新アーキテクチャへ移行しよう 81
82. アーキテクチャ移行の2つの壁 • インフラの移行 • コードの大幅な変更 82
83. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 83
84. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 84
85. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 ▪ もともとは Serverless Framework を使って Lambda の一関数に プロジェクトを丸ごとデプロイしていた 85
86. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 ▪ もともとは Serverless Framework を使って Lambda の一関数に プロジェクトを丸ごとデプロイしていた ▪ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される 86
87. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 ▪ もともとは Serverless Framework を使って Lambda の一関数に プロジェクトを丸ごとデプロイしていた ▪ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される ▪ Vercel の Pro プランではエンドポイント数は上限が 24 ……移行が 決まった段階で、エンドポイント数は約 40 …… 87
88. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 ▪ もともとは Serverless Framework を使って Lambda の一関数に プロジェクトを丸ごとデプロイしていた ▪ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される ▪ Vercel の Pro プランではエンドポイント数は上限が 24 ……移行が 決まった段階で、エンドポイント数は約 40 …… ▪ 上記はあくまで SSR が必要なエンドポイントの数であり、SSG さ れるページは含まれない 88
89. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 ▪ もともとは Serverless Framework を使って Lambda の一関数に プロジェクトを丸ごとデプロイしていた ▪ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される ▪ Vercel の Pro プランではエンドポイント数は上限が 24 ……移行が 決まった段階で、エンドポイント数は約 40 …… ▪ 上記はあくまで SSR が必要なエンドポイントの数であり、SSG さ れるページは含まれない • コードを先に修正してから Vercel へ移行する必要がある 89
90. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ 250MB問題 90
91. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ 250MB問題 ▪ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を 使うためにアップデートが必要 91
92. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ 250MB問題 ▪ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を 使うためにアップデートが必要 ▪ Lambda へデプロイするパッケージの容量の上限は 250MB で、 Next.js をアップデートすると超過することが発覚 92
93. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ 250MB問題 ▪ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を 使うためにアップデートが必要 ▪ Lambda へデプロイするパッケージの容量の上限は 250MB で、 Next.js をアップデートすると超過することが発覚 • Vercel へ先に移行してからコードを修正する必要がある 93
94. つまり 94
95. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 → Vercel へ移行するには SSG, ISR のコードに変える必要がある ◦ 250MB問題 → SSG, ISR のコードに変えるには Vercel へ移行する必要がある 95
96. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ Function 数問題 → Vercel へ移行するには SSG, ISR のコードに変える必要がある ◦ 250MB問題 → SSG, ISR のコードに変えるには Vercel へ移行する必要がある Vercel の Pro プランで運用するには、インフラ移行と アーキテクチャ移行（Next.jsのアプデを含む）を同時 に行う必要がある → 96
97. リスクが大きすぎる 97
98. Enterprise プランにしました 98
99. Enterprise プランにしました Vercel移行 → Next.jsのアプデ → SSG+ISR 99
100. アーキテクチャ移行の2つの壁 [1/2] • インフラの移行 ◦ 補足 ▪ Vercel の Pro プランの上限の中でやりくりしようとした結果複雑な ことになったが、実は2020年秋ごろに Hobby プラン以外は上限が 撤廃されたらしい ▪ 事業のさらなる拡大により、Enterprise プランでないと帯域幅の上 限に引っかかることとなりました 100
101. アーキテクチャ移行の2つの壁 [2/2] • コードの大幅な変更 101
102. アーキテクチャ移行の2つの壁 [2/2] • コードの大幅な変更 ◦ getInitialProps の廃止 ▪ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 102
103. アーキテクチャ移行の2つの壁 [2/2] • コードの大幅な変更 ◦ getInitialProps の廃止 ▪ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 ◦ OGP が必要なページは getStaticProps を使用 103
104. アーキテクチャ移行の2つの壁 [2/2] • コードの大幅な変更 ◦ getInitialProps の廃止 ▪ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 ◦ OGP が必要なページは getStaticProps を使用 ◦ OGP が必要な動的ページは getStaticProps + getStaticPaths による ISR 104
105. アーキテクチャ移行の2つの壁 [2/2] • コードの大幅な変更 ◦ getInitialProps の廃止 ▪ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 ◦ OGP が必要なページは getStaticProps を使用 ◦ OGP が必要な動的ページは getStaticProps + getStaticPaths による ISR ◦ その他、getInitialProps を前提に書かれた HOC の廃止も…… 105
106. なんとか倒しきりました （2021/4 運用開始） 106
107. インフラ・アーキテクチャ新旧 アーキテクチャ インフラ 旧 SSR Serverless Framework + AWS Lambda 新 SSG + ISR Vercel 107
108. その他色々な変遷 • Hooks 導入 ◦ クラスコンポーネントの撲滅 • Redux → Recoil ◦ Hooks や非同期処理との相性を考えて移行中 • LPを爆速で作れる仕組み ◦ Pococha の LP を支える技術 - DeNA Design ◦ Figma プラグインを作って Pococha の LP 実装をほぼ自動化した · DeNA Engineers' Blog 108
109. 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史 フレームワーク移行 3. Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 4. 展望 109
110. あるべき姿に向けて 110
111. あるべき姿に向けて • レポジトリの分割 ◦ コード修正時に影響範囲を限定できる & QA工数の削減 111
112. あるべき姿に向けて • レポジトリの分割 ◦ コード修正時に影響範囲を限定できる & QA工数の削減 • Vercel のプロジェクト運用を整備したい ◦ レポジトリ連携が出来ないので、開発環境のドメインの数だけプロジェクトが 乱立している ◦ レポジトリ連携が GH:E 対応したら、ひとつのプロジェクトへまとめたい 112
113. あるべき姿に向けて • レポジトリの分割 ◦ コード修正時に影響範囲を限定できる & QA工数の削減 • Vercel のプロジェクト運用を整備したい ◦ レポジトリ連携が出来ないので、開発環境のドメインの数だけプロジェクトが 乱立している ◦ レポジトリ連携が GH:E 対応したら、ひとつのプロジェクトへまとめたい • 技術的負債の排除 ◦ Rails に残っている Web ページの移行 ◦ クラスコンポーネントの撲滅 113
114. あるべき姿に向けて • レポジトリの分割 ◦ コード修正時に影響範囲を限定できる & QA工数の削減 • Vercel のプロジェクト運用を整備したい ◦ レポジトリ連携が出来ないので、開発環境のドメインの数だけプロジェクトが 乱立している ◦ レポジトリ連携が GH:E 対応したら、ひとつのプロジェクトへまとめたい • 技術的負債の排除 ◦ Rails に残っている Web ページの移行 ◦ クラスコンポーネントの撲滅 • まだまだやりたいことがある ◦ 新機能開発, 各工程での効率化, etc... 114
115. まとめ 115
116. まとめ • Pocochaにおけるフロントエンドの領域 • Pocochaにおけるフロントの歴史 フレームワーク移行 • Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 • 展望 116
117. まとめ • Pocochaにおけるフロントエンドの領域 ◦ WebView, Web版, 公式サイト等、多岐にわたる • Pocochaにおけるフロントの歴史 フレームワーク移行 • Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 • 展望 117
118. まとめ • Pocochaにおけるフロントエンドの領域 ◦ WebView, Web版, 公式サイト等、多岐にわたる • Pocochaにおけるフロントの歴史 フレームワーク移行 ◦ 事業拡大に耐えうるフレームワークへ • Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 • 展望 118
119. まとめ • Pocochaにおけるフロントエンドの領域 ◦ WebView, Web版, 公式サイト等、多岐にわたる • Pocochaにおけるフロントの歴史 フレームワーク移行 ◦ 事業拡大に耐えうるフレームワークへ • Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 ◦ 技術的負債を残さない開発へ • 展望 119
120. まとめ • Pocochaにおけるフロントエンドの領域 ◦ WebView, Web版, 公式サイト等、多岐にわたる • Pocochaにおけるフロントの歴史 フレームワーク移行 ◦ 事業拡大に耐えうるフレームワークへ • Pocochaにおけるフロントの歴史 インフラ・アーキテクチャ変更 ◦ 技術的負債を残さない開発へ • 展望 ◦ 健全な体制で、Web ならではの価値を提供 120