BFF、Storybook、TypeScript、App Center、Sentry――Web開発者によるReact Native開発、運用のポイント：Webフロントエンドエンジニアだけでスマホアプリ開発（3）

リクルートテクノロジーズが開発している、B2Bのスマホアプリ『Airシフト メッセージ用アプリ』。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載。今回は、開発、運用における技術的なポイントについて。

[辻健人，リクルートテクノロジーズ]

　こんにちは、リクルートテクノロジーズが開発している、B2Bのスマートフォンアプリ『Airシフト メッセージ用アプリ』（以下、メッセージアプリ）でフロントエンドの開発を担当している辻です。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載「Webフロントエンドエンジニアだけでスマホアプリ開発」。今回は、開発を円滑に進めるに当たっての技術的な工夫を紹介します。

React Nativeを活用したアーキテクチャ面の工夫

API再利用のためのBFFアーキテクチャ

　メッセージアプリでは、AirシフトのWeb版のAPIを再利用するために、「Client Adapter Pattern」を参考にBFF（Backends For Frontends）を導入しています。

　一般的なWebアプリ開発においては、BFFの責務としてサーバサイドレンダリングを取り入れているのはよくあることだと思います。ただ、今回はアプリ上のUIがHTMLでは構築されていないので、サーバサイドレンダリングはしていません。ここではWebと共通のAPIを活用するために、BFFによって、レスポンスを加工したり、APIをアプリ向きに抽象化したりしています。

図1　Client Adapter Patternを参考にしたBFF構成

　このような構成にすることで、「扱うデータそのものは同じだが、求めるJSONの形式が異なる」といったケースにおいて、その差異をBFFで吸収できます。

導入するBridge用のライブラリを制限する

　メッセージアプリでは、React Nativeを活用するに当たって「Expo」ではなく、「eject」作業を行ったものをベースに開発を進めています。ejectしたプロジェクトにおける特徴の一つとして、連載第1回で少し紹介しましたが、ネイティブモジュールを「Bridge」経由で扱える利点がありました。

　Bridgeを導入するのは利点でもありますが、iOSの場合、Objective-CやSwiftの知識が必要だったり、サードパーティーのネイティブモジュールを使う場合、バージョンの追従体制を整えることも考える必要があったりします。筆者たちは、大量のネイティブモジュールを扱って開発を進めていくと、運用時にネイティブモジュールのバージョン追従コストが肥大化してしまい、運用が破綻してしまうと考えました。そこで、活用するBridgeのライブラリは、プロジェクト開始時にある程度制限し、原則、後から加えないという方向性で進めることにしました。

　具体的には、基本的にBridgeで活用するライブラリは、「Firebase」のSDKとReact Nativeコミュニティーが公開しているものに限定しました。Firebaseを扱うことで、プッシュ通知といったネイティブアプリならではの機能を手軽に取り入れることができ、かつアプリの大半はWebフロントエンドに親しいスキルで構築可能となります。React Nativeのメリットを最大限生かしつつ、堅実な保守を実現するために、基準をここに設けました。

　無計画なライブラリの活用については、React Nativeに限らず気を付けて開発することが大切だと考えています。

　例えば、外部のライブラリを活用して、そのライブラリ起因で提供しているサービスにユーザー影響のあるバグが発生したとします。そういったとき、影響度合いにもよりますが、その外部のライブラリのいち早い修正が必要です。なぜならば、当たり前ですが、ユーザーにとってはバグが起きているという事実が重要で、そのバグが外部のライブラリかどうかは知る余地もない情報だからです。

　つまり、ライブラリを導入する際は、自分たちでいざというときに面倒を見られるかどうかという観点が重要だと考えています。特に、ユーザーが触る頻度が高いUI系のライブラリでは、これらに注意する必要があります。

開発の進め方の工夫