この記事は「MEDLEY Summer Tech Blog Relay」の16日目の記事です🍉

株式会社メドレーのモバイルアプリエンジニアとして働いている奥澤です。

メドレーではFlutterを使ったアプリの開発に関わっており、現在関わっている複数のプロダクトではそれぞれFirebaseのRemote Configを利用しています。主なユースケースとしては強制アップデートやメンテナンス中のフラグ管理です。

Remote Configを使っている中で、Remote Configの力を生かし切れていないな〜と思う事例をいくつか目にしました。本記事では、「Remote Configの力をもっと引き出すためにはこうすれば良いのでは？」と考えていることを書いてみたいと思います。

ロジックをクライアントサイドに置かない

一言で言うと「ロジックをクライアントサイドに置かない」ということです。これを意識するだけで、Remote Configの力をもっと引き出せると考えています。

強制アップデートの例で考えてみます。モバイルアプリにおける強制アップデートとは、以下のようなものです。

特定バージョン未満のアプリを使用しているユーザーに対して、アプリのアップデート画面を強制的に表示する
アップデート画面から他の画面へは遷移させず、対象ユーザーのアプリの使用を制限する
アップデート画面にはアプリのアップデートを訴求するテキストを表示すると共に、アプリストアへの導線を設置してアプリストアからアプリをアップデートしてもらう

サンプルコードで考えていきます。

ロジックをクライアントサイドに置いている場合

まずは、「ロジックをクライアントサイドに置いている場合」の例を見ていきます。例えば以下のような実装が「ロジックをクライアントサイドに置いている場合」状態です（擬似コードです）。

final appVersion = Version('x.y.z');
final requiredVersion = Version(remoteConfig.getString('required_version'));
if (appVersion < requiredVersion) {
  // 強制アップデート
}

上記の例では、 appVersion < requiredVersion の部分が「クライアントサイドに置いたロジック」です。

ロジックをクライアントサイドに置かない場合

次に、「ロジックをクライアントサイドに置かない場合」の例を見ていきます。Remote Configでは、以下のようなUIでパラメータを作成します。先ほどの例では文字列型のパラメータを作成していたわけですが、今回の例ではブール型（真偽値型）のパラメータを作成します。

上記のパラメータに対して、条件を作成できます。この条件には複数の判定を入れることができ、以下の例ではビルド番号と日時の複合条件を設定しています。Remote Config側で端末の設定を元に条件判定を行うことができます。

さらに、1つのパラメータに対して、複数の条件を作成することもできます。この例では、上記のビルド番号と日時の複合条件を deprecate_v1 に、追加の条件を hotfix_v2.0.0 に指定しています。個々の条件を細かく指定できると共に、複数の条件やデフォルト値を組み合わせて設定することで、Remote Configのコンソールできめ細やかな条件設定を行うことができます。

クライアントサイドではRemote Configの真偽値を購読することで、ロジックを書くことなく、最新の設定値を柔軟に受け取ることができるようになります。今回は真偽値を例に説明しましたが、Remote Configでは真偽値の他にも文字列・数値・JSONをサポートしており、これらについても同様にRemote Config側にロジックを置くことができます。Remote Config側にロジックを置くことで、その力を最大限に引き出すことができます。

おまけ：Remote Configの有料化

つい先日、Remote Configが有料化するとのお知らせがありました。

1日あたりのRemote Configのfetch数に応じて課金されるモデルで、1日あたり100,000回以下のfetchについては無料、それを超えるfetchについてはfetchごとに0.000006〜0.000001ドルが請求されます。

Remote Configはこれまで完全無料で提供されてきましたが、今後はコストパフォーマンスを意識した設計も必要になりそうです。

We are Hiring!

メドレーでは一緒に働く仲間を募集しています！ご興味のある方、ぜひご連絡をお待ちしております。