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

Slide 1

Slide 1 text

Pocochaにおけるフロントエンドの領域とアーキテクチャ変遷菰原裕 1

Slide 2

Slide 2 text

自己紹介 ● 菰原裕 / Yu Komohara ● 2018年DeNA新卒入社 ○ Pococha事業部システム部 ○ イベントチームでバックエンド開発 ○ その後Webチームでフロントエンド開発 ■ Rails, React, Next.js, ... 2

Slide 3

Slide 3 text

今日お話すること 1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史フレームワーク移行 3. Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 4. 展望 3

Slide 4

Slide 4 text

今日お話しないこと ● フレームワークの基礎（Rails, Next.js） ○ 一部機能の紹介はいたします ● 使用ライブラリの詳細（React, Redux, etc...） ● 実装パターン（Hooks, HOC, 各種 API, etc...） 4

Slide 5

Slide 5 text

1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史フレームワーク移行 3. Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 4. 展望 5

Slide 6

Slide 6 text

Pocochaとは ● 2017年にサービスが開始したライブ配信アプリ ● 配信をするライバーと、コメントやアイテムで応援するリスナーの双方向コミュニケーション ● 様々な形式のイベントが行われている 6

Slide 7

Slide 7 text

Webの領域 7

Slide 8

Slide 8 text

Webの領域 ● アプリ内WebView ● Pococha Web版 ● 公式サイト・その他Webページ（規約等） 8

Slide 9

Slide 9 text

Webの領域 ● アプリ内WebView ● Pococha Web版 ● 公式サイト・その他Webページ（規約等） 9

Slide 10

Slide 10 text

Webの領域 ● アプリ内WebView ● Pococha Web版 ● 公式サイト・その他Webページ（規約等） 10

Slide 11

Slide 11 text

Webの領域 ● アプリ内WebView ● Pococha Web版 ● 公式サイト・その他Webページ（規約等） 11

Slide 12

Slide 12 text

なぜWebを使うのか？ 12

Slide 13

Slide 13 text

Webで実装する意味 ● 企画の PDCA・仮説検証が回しやすい（主にWeb版） 13

Slide 14

Slide 14 text

Webで実装する意味 ● 企画の PDCA・仮説検証が回しやすい（主にWeb版） ○ 本番反映や取り下げが容易 14

Slide 15

Slide 15 text

Webで実装する意味 ● 企画の PDCA・仮説検証が回しやすい（主にWeb版） ○ 本番反映や取り下げが容易 ○ ネイティブのリリースサイクルに影響されない（Pococha なら二週間に一回） 15

Slide 16

Slide 16 text

Webで実装する意味 ● 企画の PDCA・仮説検証が回しやすい（主にWeb版） ○ 本番反映や取り下げが容易 ○ ネイティブのリリースサイクルに影響されない（Pococha なら二週間に一回） ● iOS, Android の両方で WebView さえ用意してあげればクロスプラットフォーム 16

Slide 17

Slide 17 text

Webで実装する意味 ● 企画の PDCA・仮説検証が回しやすい（主にWeb版） ○ 本番反映や取り下げが容易 ○ ネイティブのリリースサイクルに影響されない（Pococha なら二週間に一回） ● iOS, Android の両方で WebView さえ用意してあげればクロスプラットフォーム ● エンジニアリソースを有効活用できる 17

Slide 18

Slide 18 text

以上が、Pocochaにおける Webフロントエンドの領域の話です 18

Slide 19

Slide 19 text

ここから、その変遷をお話いたします 19

Slide 20

Slide 20 text

1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史フレームワーク移行 3. Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 4. 展望 20

Slide 21

Slide 21 text

初期（2017/1〜2018/11） ● Rails が API サーバと Web サーバの両方の役割を担う 21

Slide 22

Slide 22 text

初期（2017/1〜2018/11） ● Rails が API サーバと Web サーバの両方の役割を担う ● 試行錯誤をしていた段階で、ページごと（イベントはイベントごと）にUIが異なり、マスターデータを元に動的にページを生成できない 22

Slide 23

Slide 23 text

初期（2017/1〜2018/11） ● Rails が API サーバと Web サーバの両方の役割を担う ● 試行錯誤をしていた段階で、ページごと（イベントはイベントごと）にUIが異なり、マスターデータを元に動的にページを生成できない ● ページ数が少ないので、なんとかコピペ運用で回せていた時期 23

Slide 24

Slide 24 text

事業拡大に伴う課題 24

Slide 25

Slide 25 text

事業拡大に伴う課題 ● 自動化されても辛いコピペ運用 25

Slide 26

Slide 26 text

事業拡大に伴う課題 ● 自動化されても辛いコピペ運用 ○ イベント数の増加 26

Slide 27

Slide 27 text

事業拡大に伴う課題 ● 自動化されても辛いコピペ運用 ○ イベント数の増加 ○ フォーマットも固まってきたので、ページを共通化したい 27

Slide 28

Slide 28 text

事業拡大に伴う課題 ● 自動化されても辛いコピペ運用 ○ イベント数の増加 ○ フォーマットも固まってきたので、ページを共通化したい ● LP のような、フロントで完結するページを Rails で作るのは辛い 28

Slide 29

Slide 29 text

事業拡大に伴う課題 ● 自動化されても辛いコピペ運用 ○ イベント数の増加 ○ フォーマットも固まってきたので、ページを共通化したい ● LP のような、フロントで完結するページを Rails で作るのは辛い ● リッチな UI を JS でゴリゴリ書きたい 29

Slide 30

Slide 30 text

新フレームワークへ移行しよう 30

Slide 31

Slide 31 text

当時（2018年夏頃）検討された選択肢 31

Slide 32

Slide 32 text

当時（2018年夏頃）検討された選択肢 ● Angular ● React + React Helmet ● Vue + Nuxt.js ● React + Next.js 32

Slide 33

Slide 33 text

当時（2018年夏頃）検討された選択肢 ● Angular ○ 半年に一度の破壊的なメジャーアップデート ● React + React Helmet ● Vue + Nuxt.js ● React + Next.js 33

Slide 34

Slide 34 text

当時（2018年夏頃）検討された選択肢 ● Angular ○ 半年に一度の破壊的なメジャーアップデート ● React + React Helmet ○ webpack や Babel や Express を自前で入れて管理する必要がある ● Vue + Nuxt.js ● React + Next.js 34

Slide 35

Slide 35 text

当時（2018年夏頃）検討された選択肢 ● Angular ○ 半年に一度の破壊的なメジャーアップデート ● React + React Helmet ○ webpack や Babel や Express を自前で入れて管理する必要がある ● Vue + Nuxt.js ○ SSR (後述)は出来るが、当時（Vue 2）ビューにロジックを含めたくなかった ● React + Next.js 35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

移行ステップ ● React + Next.js のプロジェクトを立ち上げる ○ ページを作る ○ 認証機構を実装する ○ デプロイフローを整える ● フロント側にデータを渡す仕組みを作る ○ データフォーマットを定める（csv, yaml） ○ API を Rails に生やす 37

Slide 38

Slide 38 text

React + Next.js に移行しました（2018/12 運用開始） 38

Slide 39

Slide 39 text

簡易構成図（〜2018/12） 39

Slide 40

Slide 40 text

簡易構成図（2018/12〜） 40

Slide 41

Slide 41 text

簡易構成図（2018/12〜） ※現在も Rails から Next.js へページを移行中 41

Slide 42

Slide 42 text

事業拡大に伴う課題（再掲） ● 自動化されても辛いコピペ運用 ● LP のような、フロントで完結するページを Rails で作るのが辛い ● リッチな UI を JS でゴリゴリ書きたい 42

Slide 43

Slide 43 text

事業拡大に伴う課題（再掲） ● 自動化されても辛いコピペ運用 ○ API 側にマスターデータを保持してページに流し込む形式 ● LP のような、フロントで完結するページを Rails で作るのが辛い ● リッチな UI を JS でゴリゴリ書きたい 43

Slide 44

Slide 44 text

事業拡大に伴う課題（再掲） ● 自動化されても辛いコピペ運用 ○ API 側にマスターデータを保持してページに流し込む形式 ● LP のような、フロントで完結するページを Rails で作るのが辛い ○ LP を Rails に載せる必要がなくなった ● リッチな UI を JS でゴリゴリ書きたい 44

Slide 45

Slide 45 text

事業拡大に伴う課題（再掲） ● 自動化されても辛いコピペ運用 ○ API 側にマスターデータを保持してページに流し込む形式 ● LP のような、フロントで完結するページを Rails で作るのが辛い ○ LP を Rails に載せる必要がなくなった ● リッチな UI を JS でゴリゴリ書きたい ○ Rails の制約がないので好きに書ける 45

Slide 46

Slide 46 text

すべて解決！！ 46

Slide 47

Slide 47 text

そんなことはなく 47

Slide 48

Slide 48 text

1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史フレームワーク移行 3. Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 4. 展望 48

Slide 49

Slide 49 text

CSR と SSR 49

Slide 50

Slide 50 text

CSR(Client Side Rendering) 1. ユーザがリクエストを送る 2. サーバからのレスポンス後に JS がクライアント（ブラウザ）へダウンロードされる 3. クライアント側で JS が実行される 4. 実行が終わった段階でページが表示される 50

Slide 51

Slide 51 text

SSR(Server Side Rendering) 1. ユーザがリクエストを送る 2. リクエストが到達した段階で、サーバ側で JS が実行される 3. 初期表示用のページ（First View）をレンダリングして、レスポンスが返る 4. その後必要に応じてクライアント側でも JS が実行され、最終的なページが表示される 51

Slide 52

Slide 52 text

SSR のメリット 52

Slide 53

Slide 53 text

SSR のメリット ● UX 向上 ○ 初回レンダリングがブラウザではなくサーバで行われるので、高速 ○ ブラウザでの JS の実行を待たずに描画されるため、空白ページやインジケータが表示されない 53

Slide 54

Slide 54 text

SSR のメリット ● UX 向上 ○ 初回レンダリングがブラウザではなくサーバで行われるので、高速 ○ ブラウザでの JS の実行を待たずに描画されるため、空白ページやインジケータが表示されない ● SEO ○ 必要な情報をサーバ側でレンダリングした上でレスポンスが返るので /users/[userId] のような動的なルーティングでも OGP を設定できる ○ クローラに関しては、レンダリングのタイムラグ以外は問題ない 54

Slide 55

Slide 55 text

SSR のデメリット 55

Slide 56

Slide 56 text

SSR のデメリット ● 自前で導入するのは難しい ○ フレームワークに依存することになる 56

Slide 57

Slide 57 text

SSR のデメリット ● 自前で導入するのは難しい ○ フレームワークに依存することになる ● コードが煩雑になる ○ Next.js（当時は 9.1.6）では getInitialProps という SSR でも CSR でも呼ばれるライフサイクルがあり、Universal JS を意識する必要があった 57

Slide 58

Slide 58 text

SSR のデメリット ● 自前で導入するのは難しい ○ フレームワークに依存することになる ● コードが煩雑になる ○ Next.js（当時は 9.1.6）では getInitialProps という SSR でも CSR でも呼ばれるライフサイクルがあり、Universal JS を意識する必要があった ○ SSR はサーバ側（Node 環境）で実行されシングルスレッドで動作し、シングルスレッドで固有の問題も生じうる 58

Slide 59

Slide 59 text

SSR をやめたい…… 59

Slide 60

Slide 60 text

そんな中 60

Slide 61

Slide 61 text

getStaticProps の登場 ● Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に実行されるライフサイクル 61

Slide 62

Slide 62 text

getStaticProps の登場 ● Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に実行されるライフサイクル ● SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた静的コンテンツが返るので、レスポンスが早い 62

Slide 63

Slide 63 text

Slide 64

Slide 64 text

getStaticProps の登場 ● Next.js 9.3（2020/3）から追加された、SSG(Static Site Generation) 時に実行されるライフサイクル ● SSG 自体は一般的な方式であり、 SSR と異なりサーバ側で事前にビルドされた静的コンテンツが返るので、レスポンスが早い ● Next.js にも静的に書き出す機能や自動的に SSG される機構が存在したが、9.3 で専用のライフサイクルが登場した ● 動的ページで SSG を実装するための getStaticPaths というライフサイクルも同時に登場 64

Slide 65

Slide 65 text

Slide 66

Slide 66 text

SSGの実装 ● www.example.com/entries のような一覧ページ 66

Slide 67

Slide 67 text

SSGの実装 ● www.example.com/entries のような一覧ページ ● ビルド時に getStaticProps が実行され、一覧情報が API から取得される 67

Slide 68

Slide 68 text

SSGの実装 ● www.example.com/entries のような一覧ページ ● ビルド時に getStaticProps が実行され、一覧情報が API から取得される ● getStaticProps の return がコンポーネントへ渡され、APIで取得した情報を元に事前にビルドされる 68

Slide 69

Slide 69 text

SSGの実装（動的ルーティング） ● www.example.com/entries/[entryId] のような詳細ページ 69

Slide 70

Slide 70 text

SSGの実装（動的ルーティング） ● www.example.com/entries/[entryId] のような詳細ページ ● getStaticPaths で、事前にどの ID のページについて SSG するかを指定する 70

Slide 71

Slide 71 text

SSGの実装（動的ルーティング） ● www.example.com/entries/[entryId] のような詳細ページ ● getStaticPaths で、事前にどの ID のページについて SSG するかを指定する ● それぞれのページについて、ページ内容を getStaticProps で API から取得する 71

Slide 72

Slide 72 text

SSGの実装（動的ルーティング） ● www.example.com/entries/[entryId] のような詳細ページ ● getStaticPaths で、事前にどの ID のページについて SSG するかを指定する ● それぞれのページについて、ページ内容を getStaticProps で API から取得する ● getStaticProps の return がコンポーネントへ渡され、getStaticPaths で指定した全てのパスについて事前ビルドが行われる 72

Slide 73

Slide 73 text

事前にビルドするページ数が膨大だったら……？ 73

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

ISG(Incremental Static Generation) ● getStaticProps 等と同じく Next.js 9.3（2020/3）で追加 ● getStaticPaths で fallback を false 以外に指定した場合に有効化 ● 事前ビルドしていないページへリクエストが到達した段階でインクリメンタルに SSG を実行し、以後そのページへのリクエストには SSG されたコンテンツが返る 76

Slide 77

Slide 77 text

一度 SSG されたページの内容が変更されたら……？ 77

Slide 78

Slide 78 text

一度 SSG されたページの内容が変更されたら……？実際に、エラーページをキャッシュしてしまう障害を起こしたこともありました 78

Slide 79

Slide 79 text

ISR(Incremental Static Regeneration) ● Next.js 9.5（2020/7）で追加 ● getStaticProps の return で revalidate を指定した場合に有効化 ● revalidate で指定した秒数の経過後、新しいリクエストが来たら、再度 SSG を実行する（= キャッシュを更新する） 79

Slide 80

Slide 80 text

SSR → SSG + ISR 80

Slide 81

Slide 81 text

新アーキテクチャへ移行しよう 81

Slide 82

Slide 82 text

アーキテクチャ移行の2つの壁 ● インフラの移行 ● コードの大幅な変更 82

Slide 83

Slide 83 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 83

Slide 84

Slide 84 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 84

Slide 85

Slide 85 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 ■ もともとは Serverless Framework を使って Lambda の一関数にプロジェクトを丸ごとデプロイしていた 85

Slide 86

Slide 86 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 ■ もともとは Serverless Framework を使って Lambda の一関数にプロジェクトを丸ごとデプロイしていた ■ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される 86

Slide 87

Slide 87 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 ■ もともとは Serverless Framework を使って Lambda の一関数にプロジェクトを丸ごとデプロイしていた ■ Vercel へデプロイすると、SSR をするエンドポイントごと（page ごと）に関数が分割される ■ Vercel の Pro プランではエンドポイント数は上限が 24 ……移行が決まった段階で、エンドポイント数は約 40 …… 87

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ 250MB問題 90

Slide 91

Slide 91 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ 250MB問題 ■ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を使うためにアップデートが必要 91

Slide 92

Slide 92 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ 250MB問題 ■ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を使うためにアップデートが必要 ■ Lambda へデプロイするパッケージの容量の上限は 250MB で、 Next.js をアップデートすると超過することが発覚 92

Slide 93

Slide 93 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ 250MB問題 ■ 当時使用していた Next.js のバージョンは 9.1.6 で、SSG や ISR を使うためにアップデートが必要 ■ Lambda へデプロイするパッケージの容量の上限は 250MB で、 Next.js をアップデートすると超過することが発覚 ● Vercel へ先に移行してからコードを修正する必要がある 93

Slide 94

Slide 94 text

つまり 94

Slide 95

Slide 95 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 → Vercel へ移行するには SSG, ISR のコードに変える必要がある ○ 250MB問題 → SSG, ISR のコードに変えるには Vercel へ移行する必要がある 95

Slide 96

Slide 96 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ Function 数問題 → Vercel へ移行するには SSG, ISR のコードに変える必要がある ○ 250MB問題 → SSG, ISR のコードに変えるには Vercel へ移行する必要がある Vercel の Pro プランで運用するには、インフラ移行とアーキテクチャ移行（Next.jsのアプデを含む）を同時に行う必要がある → 96

Slide 97

Slide 97 text

リスクが大きすぎる 97

Slide 98

Slide 98 text

Enterprise プランにしました 98

Slide 99

Slide 99 text

Enterprise プランにしました Vercel移行 → Next.jsのアプデ → SSG+ISR 99

Slide 100

Slide 100 text

アーキテクチャ移行の2つの壁 [1/2] ● インフラの移行 ○ 補足 ■ Vercel の Pro プランの上限の中でやりくりしようとした結果複雑なことになったが、実は2020年秋ごろに Hobby プラン以外は上限が撤廃されたらしい ■ 事業のさらなる拡大により、Enterprise プランでないと帯域幅の上限に引っかかることとなりました 100

Slide 101

Slide 101 text

アーキテクチャ移行の2つの壁 [2/2] ● コードの大幅な変更 101

Slide 102

Slide 102 text

アーキテクチャ移行の2つの壁 [2/2] ● コードの大幅な変更 ○ getInitialProps の廃止 ■ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 102

Slide 103

Slide 103 text

アーキテクチャ移行の2つの壁 [2/2] ● コードの大幅な変更 ○ getInitialProps の廃止 ■ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 ○ OGP が必要なページは getStaticProps を使用 103

Slide 104

Slide 104 text

アーキテクチャ移行の2つの壁 [2/2] ● コードの大幅な変更 ○ getInitialProps の廃止 ■ コンポーネントのレンダリング時にリクエストを投げる CSR 方式へ移行 ○ OGP が必要なページは getStaticProps を使用 ○ OGP が必要な動的ページは getStaticProps + getStaticPaths による ISR 104

Slide 105

Slide 105 text

Slide 106

Slide 106 text

なんとか倒しきりました（2021/4 運用開始） 106

Slide 107

Slide 107 text

インフラ・アーキテクチャ新旧アーキテクチャインフラ旧 SSR Serverless Framework + AWS Lambda 新 SSG + ISR Vercel 107

Slide 108

Slide 108 text

その他色々な変遷 ● Hooks 導入 ○ クラスコンポーネントの撲滅 ● Redux → Recoil ○ Hooks や非同期処理との相性を考えて移行中 ● LPを爆速で作れる仕組み ○ Pococha の LP を支える技術 - DeNA Design ○ Figma プラグインを作って Pococha の LP 実装をほぼ自動化した · DeNA Engineers' Blog 108

Slide 109

Slide 109 text

1. Pocochaにおけるフロントエンドの領域 2. Pocochaにおけるフロントの歴史フレームワーク移行 3. Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 4. 展望 109

Slide 110

Slide 110 text

あるべき姿に向けて 110

Slide 111

Slide 111 text

あるべき姿に向けて ● レポジトリの分割 ○ コード修正時に影響範囲を限定できる & QA工数の削減 111

Slide 112

Slide 112 text

あるべき姿に向けて ● レポジトリの分割 ○ コード修正時に影響範囲を限定できる & QA工数の削減 ● Vercel のプロジェクト運用を整備したい ○ レポジトリ連携が出来ないので、開発環境のドメインの数だけプロジェクトが乱立している ○ レポジトリ連携が GH:E 対応したら、ひとつのプロジェクトへまとめたい 112

Slide 113

Slide 113 text

あるべき姿に向けて ● レポジトリの分割 ○ コード修正時に影響範囲を限定できる & QA工数の削減 ● Vercel のプロジェクト運用を整備したい ○ レポジトリ連携が出来ないので、開発環境のドメインの数だけプロジェクトが乱立している ○ レポジトリ連携が GH:E 対応したら、ひとつのプロジェクトへまとめたい ● 技術的負債の排除 ○ Rails に残っている Web ページの移行 ○ クラスコンポーネントの撲滅 113

Slide 114

Slide 114 text

Slide 115

Slide 115 text

まとめ 115

Slide 116

Slide 116 text

まとめ ● Pocochaにおけるフロントエンドの領域 ● Pocochaにおけるフロントの歴史フレームワーク移行 ● Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 ● 展望 116

Slide 117

Slide 117 text

まとめ ● Pocochaにおけるフロントエンドの領域 ○ WebView, Web版, 公式サイト等、多岐にわたる ● Pocochaにおけるフロントの歴史フレームワーク移行 ● Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 ● 展望 117

Slide 118

Slide 118 text

まとめ ● Pocochaにおけるフロントエンドの領域 ○ WebView, Web版, 公式サイト等、多岐にわたる ● Pocochaにおけるフロントの歴史フレームワーク移行 ○ 事業拡大に耐えうるフレームワークへ ● Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 ● 展望 118

Slide 119

Slide 119 text

まとめ ● Pocochaにおけるフロントエンドの領域 ○ WebView, Web版, 公式サイト等、多岐にわたる ● Pocochaにおけるフロントの歴史フレームワーク移行 ○ 事業拡大に耐えうるフレームワークへ ● Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 ○ 技術的負債を残さない開発へ ● 展望 119

Slide 120

Slide 120 text

まとめ ● Pocochaにおけるフロントエンドの領域 ○ WebView, Web版, 公式サイト等、多岐にわたる ● Pocochaにおけるフロントの歴史フレームワーク移行 ○ 事業拡大に耐えうるフレームワークへ ● Pocochaにおけるフロントの歴史インフラ・アーキテクチャ変更 ○ 技術的負債を残さない開発へ ● 展望 ○ 健全な体制で、Web ならではの価値を提供 120

Slide 121

Slide 121 text

121