JSConf 2019 Proposal
Title
Migration from React Native to PWA
Talk Overview
対象とする聞き手
クロスプラットフォーム開発フレームワークによるアプリ開発やマルチプラットフォーム対応を考えている方
すでにネイティブ言語以外でのネイティブアプリ開発・運用をしており、マイグレーションを考えている方
React Nativeの利用経験は問いません
トークの内容
ここ数年でReact Nativeの導入・運用事例や、Airbnbの例に代表されるようにReact Nativeアプリをネイティブ言語で刷新する事例も耳聞するところとなりました。また、そうした時流での技術選定について「React Native VS PWA」「React Native VS Swift/Kotlin」のような二項対立で評価が行われることもあります。しかし、React NativeからPWAへと移行した事例について聞くことは多くありません。
このトークは、React Nativeで作られたアプリをPWAとして刷新したプロジェクトの事例を通じて得られた知見について話すケーススタディです。具体的には「"開発できる"は"運用できる"を意味しない」という辛みと、改めて気づく「Webというプラットフォームの開発体験の良さ」が軸になる予定です。
同アプリが業務システムであることなど固有の事情もこの事例では含みますが、発表を通じて以下のことをお伝えします。
React Native appからPWAに移行するに至った経緯、技術選定
移行において工夫したこと
以下の2パターンのアプリケーションの開発・運用で学んだこと
iOS/Android両プラットフォーム対応しているReact Native app
iOS/Android/Webの3つのプラットフォームに対応するPWA/Hybrid app
参考リンク
Pitch
この発表の目的、価値、参加者に届けたいこと
React Native appからPWAに移行するに至った経緯
以下の開発・運用で学んだこと
iOS/Android両プラットフォーム対応しているReact Native app
iOS/Android/Webの3プラットフォームに対応するPWA/Hybrid app
技術選定の判断材料（どういうシチュエーションならどちらを選ぶか）
React Nativeにすべきか
PWAを採用すべきか
対象者
React NativeやFlutterなどネイティブ言語以外でのネイティブアプリ開発やマルチプラットフォーム対応を考えている方
React, React Nativeの利用経験は問わない
すでにネイティブ言語以外でのネイティブアプリ開発・運用をしている方
登壇者について
サーバサイド寄りのWeb engineer
React, TypeScript (1.5 years)
Ruby on Rails (4 years)
iOS/Android両プラットフォーム対応しているReact Nativeアプリの開発・運用で挫折した
React NativeアプリをReactのPWAにマイグレーションするプロジェクトを実行した（主にサーバサイド）
APIの設計・実装
Kubernetesクラスタ上へのデプロイ
OpenAPIによる仕様の記述
話そうと考えていること
導入（5分）
対象のReact Native appの説明
Quipperが開発しているスタディサプリのサービス説明
合格特訓プランという現役大学生コーチによる学習伴走サービスを提供している
コーチとユーザーのコミュニケーションをより円滑にする為の、メッセージ機能をベースとした業務補助アプリ
約500名のアルバイト社員が利用する
iOS/Android両プラットフォーム対応
iOS版は約2年運用
Android版は約1年運用
チャットアプリ
すべての機能が React で実装されている
会社と契約したアルバイトスタッフが使用するアプリなので App store/Google play storeで公開せず、DeployGateでアプリを配信
上記の理由からApple/Googleのアプリ審査はなし
React Native採用の背景
本題のアウトライン（20分）
Part 1: React Native appの開発・運用（5分）
既存の土台の上にUIをガリガリ書いていくぶんには大変ではない
React, Reduxの知識があれば十分だし、インターンでもキャッチアップできる
マルチプラットフォーム対応が大変
React Native関連のUIライブラリがマルチプラットフォームを完全にサポートしているケースが稀有
既存機能でもiOSで動くかAndroidでは壊れているものが複数ある
React Nativeアップグレードが大変
iOSのバージョンアップデートに伴って必須となる
Xcode をあげないといけない -> react-native もあげないといけない -> それに合わせて react , redux, typescript もろもろ dependency あげないといけない
モブプロしたりしたが負けた
ビルド・デプロイシステムが大変
native知識が必要
壊れているのをマシにするレベルのところをネイティブエンジニアに1ヶ月近くかけてやってもらったが、これ以上時間を突っ込むのは厳しいと判断
ライブラリ管理が大変
少なくともwebエンジニアの考えるbundlerやnpmとは違う考え方で管理しないといけなかった
Pods/ とか Carthage/Checkouts/ とかをリポジトリに含めないとビルドできなくなることがある
上述のような状況にあり、開発どころかリリースにすら恐怖する状態になってしまった
Part 2: Migration plan（10分）
設計
PWA化 or ネイティブアプリ化で議論し、以下の理由でPWAに決定
Webアプリとして利用したいという要望
ネイティブ言語で両プラットフォーム対応するのはコストが大きい
iOSはPush通知を受け取るためにHybrid app（ガワアプリ）として使う
フロントエンドの技術選定
社内で知見があるReact, TypeScript
React Nativeのコンポーネントをそのまま移植できる可能性があったのでreact-native-webも検討したが旨味が少ないのでやめた
React Nativeのためのライブラリの代替がReact用に存在するかチェック
大抵はUIコンポーネントライブラリだった
PWAとしてどこまでの機能を搭載すべきか判断
Push通知、カメラ、etc.
インフラ面の設計
Kubernetes上にPodを立てる
Pod内にはビルドしたアセットを配信するNginxを立てる
CIはAPIとインテグレーションされている状態にした
React Nativeのときは別レポジトリだった
開発
iOS Hybrid appとJavaScriptの間のブリッジコードをそれなりに書く必要がある
型定義をちゃんと書いていく
モバイル端末でのデバグ
動作確認が楽
デバグしやすい
発生するエラーがReact Nativeに比べて馴染みがあるものばかり
ハマったポイント
テスト
React Nativeとは異なるテストツールを選択した
React Nativeの場合テストの選択肢が限定されることがある
React component testing
実質react-test-rendererに限定される
DOMやnative moduleでなくJavaScript objectを吐き出せる
Snapshot testingが中心だったが良くない方針だった
E2E/Integration testingはやっていなかった
JavaScriptで書け、ビルド済のアプリに対して実行できる
React SPA
以下のロードマップで進めた
Integration
Bridge周りや複雑なロジック
Component test
以下はやらない方向
Snapshot testing
Part3: PWAの運用（5分）
リリースすると即時反映
React NativeにおけるOTAも同じことだが、Nativeコード依存がさらに減ったのでアプリ再インストールの手間削減
PWAとAPIをmonorepoで管理できるようになった
それぞれの変更を同時にかつatomicに行える
staging環境に両方をセットでデプロイできる
APIの設計思想が少し変わった
ネイティブアプリはリリース時に再インストールが必要になるのでなるべくバックエンドAPIを賢くしたい
SPAにすることでリリースのハードルが下がり、バックエンドは純粋にデータをexposeするだけの存在に近づいた
フロント側の事情はフロントで処理すればよい
以前は時刻に依存してレスポンスが変わるようなAPI endpointがあってキャッシュしづらかったが、クライアント側に処理を移すことで速度面での向上があった
我々の業務用アプリでは恩恵を受けないが、Google Play Storeの審査スピードが早くない問題に対して有効に思える
時間が余れば質疑応答（5分）
なぜ私が登壇すべきと考えているのか？
React Native採用・運用事例は多く聞くが、Migration from React Native to PWAの事例は少ない
iOS/Androidエンジニアが充実したことでNative appsの開発に注力できるようになったというシナリオはよくありそう
「React Native VS PWA」「React Native VS Swift/Kotlin」という2項対立で「どちらを選ぶべきか」の観点でメリット・デメリットが語られることは多いが、マイグレーションという観点で語るものは多くない
懸念点
サーバサイド寄りのエンジニアの観点での気付きが中心になることが予想される
JSConfというイベントでReact Nativeといった特定技術の話をするのは好まれないかもしれない
biography
Quipperで教育サービス「スタディサプリ」の開発・運用をしています。Ruby on RailsによるWeb application、mobile application向けAPI開発、Single Page Application開発が主な業務内容です。
また、Engineering Manager Meetupというイベントを主催しています。
Masato Ohba (@ohbarye) is currently an engineering manager at Quipper and works for StudySapuri, which is one of the most popular education services in Japan. He mainly develops web applications with Ruby on Rails and single page applications written in React.
Besides his work, he recently started organizing an event and a community named Engineering Manager Meetup.