FirebaseかReduxか？

FirebaseかReduxか？

React を使って、フロントエンドの実装をする場合、アプリの規模が大きくなると扱うデータを一言管理した方がデータを管理しやすくなる場合が多くなります。その場合、よく利用されるのが Redux です。

ところが、この Redux は最初は中々分かりにくい代物です。特にプログラミングの初心者には分かりにくい分野の一つだと思います。

この記事では、Web アプリで使うデータの扱いを改めて考えてみました。

ハードウエア設計支援のアプリの開発を例にすると

現在、行っている開発の一つに、コンピュータのハードウエア、特にコンピュータで使うプリント基板の設計支援アプリがあります。開発の詳細は書くことができませんが、比較的大きなデータを扱うアプリです。

前回はこの、設計データの一部のファイルが非常に大きく、ファイルアクセスの性能評価の指標に使って M1 Mac のシステム性能を実際のデータで見てみました。行数は百万行以上になる物もあります。

ある機能では、そうしたデータのファイルを３種類読み込んで処理を行う必要があって、データの容量だけでも、数ギガバイトになります。

ハードウエアの開発を行う場合、開発に利用するアプリ自体も結構なメモリを使いますし、CPU の負荷も高くなります。

こうした処理を毎回、フロントエンドで行うと、設計者が利用している PC には相当の負荷もかかりますし、よりハイスペックな PC が必要になってきます。

いずれにせよ、元になるデータは大きいのでその処理は必要なのですが、毎回データを取り込むようなアプリの設計にすると、時間も、必要なメモリ容量や CPU の性能が必要になってきます。

シンプルな実装は？

プログラムの観点から考えると、一番シンプルな実装は、毎回必要なファイルを読み込んで、読み込んだデータを処理するというスタイルになるかと思います。フロントエンドのみの実装で、Web ブラウザで動作するアプリで完結できるのでアプリの開発は比較的シンプルです。

ところが、毎回大きなデータを取り込むため、多くの時間と PC のリソース（メモリや CPU の処理時間）が必要になります。実際は、同じデータを条件を変えて処理をして結果がみたいわけですが、実行する PC にはかなり負荷がかかります。

Web 開発の教科書的に実装を考えると、

＊　必要なデータを読み込んで Redux を使って取り込んだデータを管理

＊　Redux のデータを条件を変えて処理

＊　結果を表示

のような実装になる場合が多いかと思います。

実際は、この開発したアプリを中心で PC を使える場合はあまり大きな問題ではなく、最近の標準的な PC ならば８ GB 以上のメモリと複数のコアを持った CPU で処理できるのでなんとかなると言えます。 しかし、実際は他の設計用のアプリやドキュメントを書くための Office 系のアプリや Web ブラウザなどは常に動いている物です。

現実的には Redux に大きなデータを常駐させておくのは、利用者の利用形態を考えるとあまり良い実装とは言えません。

別の実装方法は？

一つの方法は、ファイルから読み込んだデータをバックエンドのデータベースに入れてしまうという方法があります。こうすることで、ファイルからの大量のデータの読み込みは１度だけにして、後は必要なデータのみをデータベースから取り出して、取り出したデータのみをフロントエンドで処理する。あるいは、取り出したデータもバックエンドで処理して結果のみをフロントエンドに渡すという方法があります。

当然、サーバー側の負荷は高くなりますが、利用者が使う PC の負荷はかなり軽減できます。

また、利用者の PC（端末）で使うメモリ容量も小さくて済みます。また、データの取り込みも設計を変更しない限りは、最初に取り込んだデータの必要なところだけを利用すれば良いので、処理時間も繰り返しデータを利用する場合は短くできます。

Redux を使う必要性は減る！

こうした、利用者を主体に考えた実装をする場合、Redux を利用する必要性は少なくなってきます。 それでも、ユーザー認証の情報（ログイン情報）など、Web サイト全体で共有したい場合は Redux は便利だと思いますが、Firebase を使う場合、ユーザー認証の結果も各ページから Firebase に紹介すればすぐに取れます。そう考えると、Redux が本当に必要になるアプリは結構限られて来ることになります。

Firebase を使えば全て解決できるか？

Firebase の場合、ユーザーの認証情報は簡単に取得できますし、データベースも非常に高速でアクセス可能なので、上手く Firebase を利用すると、Redux でデータを管理するケースはかなり少なくなります。

そう考えると、Firebase を使うと問題は解決のように見えます。しかし、実際はそう単純な話ではありません。実際に今回、取り上げた設計支援のアプリの場合、データの件数（行数ではありません）でも、数十万件あるので、このデータを Firebase のデータベースに書き込むだけでも、数十万回の書き込みが発生します。これが、一件の設計データの話なので、軽く Firebase の無料枠は超えてしまうことになります。

後は、どの程度の書き込みや読み込みが発生するかということになりますが、Firebase の料金体系は基本的にはデータベースの場合データの使用容量とアクセス（読み書き）の回数で料金が決まってきます。

そう考えた時に、Firebase の料金が予算内に治るかどうかは検証する必要があります。

コストの事を考えると例に挙げたケースでは、Firebase の Cloud Firestore を使うより、MySQL などの SQL のデータベースを建てて PHP などで処理するようにした方が、コストが抑えられるケースが多いと考えられます。

逆に、データ件数や容量が余り大きくないケースでは、Firebase が向いていると言えます。

実際に実装を考える際は、Web ブラウザで使うメモリ容量と、データベースに格納するデータのサイズ、件数を考えて「全体としてどう実装するかを考えた方が良い」ということになります。

まとめ

Redux はReact を学習するという意味では、重要な項目の一つであることは間違いないと言えます。しかし、実際の Web アプリの実装で重要なのは、利用者の利用形態をよく理解して、利用者の使う PC の仕様も考慮する事は良いサービスを作る上でとても重要です。

そう考えると、Redux を使う実装よりは、上手くバックエンドのデータベースを利用した方が、「端末（Web ブラウザ）に優しいアプリやサービス」になる場合もあります。

Firebase は便利な仕組みですが、料金体系を理解して利用することも大切です。大きな、件数の多いデータを扱う場合、利用料金が予想以上に高くなることもあります。利用を検討する際は、データのサイズや件数を元に、データベースのアクセス回数を見積もることも大切になります。