非常に簡単に言えば、Firebase は外部データベース サービスです。彼らは自分自身を次のように定義しています。
「Google が提供するバックエンド クラウド コンピューティング サービスとアプリケーション開発プラットフォームのセット」について詳しくは、https: //firebase.google.com/をご覧ください。
データベース サービスに加えて、さまざまなアプリケーションの認証および統合サービスも提供しています。サポートされているアプリケーションとプログラミング言語は、Flutter、Dart、C++、Android、IOS、 JavaScript 、Unity エンジン、および Java です。
なぜこれが重要なのですか?アプリケーションの開発に Firebase を使用したためです。それだけでなく、最も人気のあるサービスであるデータベース サービスを使用しました。
なぜ Firebase を使用するのでしょうか? Firebase は簡単です。ユーザーデータを何らかの形式で保存する必要がある開発プロジェクトを行う場合、データベースが必要になります。これは、後の分析、データの変更、データ保護、データの復元などのためにユーザー データを保存するためのものです。これは、企業、個人、組織、さらにはより多くのグループにも当てはまります。
データベースを使用する理由がわかったので、次の質問をする必要があります。どのデータベース タイプが適しているか?
これらの違いを調べてみましょう。それを行っている間、Firebase がどのデータベース タイプに該当するかを推測してみてください ;) 。
集中型データベース: これは、アプリケーションに使用されているデータベースが、それを使用する人が物理的に直接アクセスできる場所に格納されている場合です。また、データベースを編集、改善、更新、および再構築することもできます。基本的に、物理的、内部的、およびデジタル インフラストラクチャの観点から、データベースの完全な所有権と編集権限を持っています。
分散型データベース: これは集中型データベースとは正反対です。それらは web3 ベースのデータベースです。これらは、ストレージ デバイスがさまざまなコンピューティング デバイスに分散しているデータベースです。データベースの内部機能をカスタマイズおよび改善できるのは、特定の組織のみです。それらの使用例は限られています。それらは主に web3 アプリ、トークン、および他の web3 製品をホストするために作成されています。
それらをより完全に調査する web3 データベースの詳細については、こちらを確認してください: https://www.makeuseof.com/what-is-web3-storage-how-does-it-work/
DBaaS : このデータベース タイプは、「サーバーレス」と呼ばれることがよくあります。これは、集中型データベースに似たこのデータベース タイプでは、データベースをローカルに保持しないためです。データベースはサード パーティの会社によってホストされており、データベースの特定のデジタル インフラストラクチャをカスタマイズすることはできますが、それ以上のことはできません。このデータベースの主なセールス ポイントは、費用対効果です。独自の集中型データベースを作成するために資金を大量に費やす代わりに、その努力を外部に委託することを選択します。誰かが汚い建設作業を行い、あなたは彼らから借りて彼らのデータベース サービスを利用することができます。有料層レベルごとに異なる機能を利用できます。
DBaaS を使用することにしました。 Firebase は DBaaS です。このデータベース モデルの費用対効果の高さから、私はこれを選択しました。
アプリを作っています。アプリの機能の 1 つに、ユーザーの登録、サインイン、サインアウトがあります。上の図でわかるように、サインアップするためのテスト ユーザー名とテスト パスワードを作成しました。 「サインアップ」ボタンを押すと、アプリは関連するデータベースに情報を送信しました。 Firebase でホストされているデータベース。サインアップしようとしても、同じアプリ ページにとどまり、何も変わりませんでした。 Firebase でユーザーを確認したところ、その時点で新しいユーザーは登録されていませんでした。これは、ユーザーが登録されていないことを意味します。
新しいユーザーを認識するためにアプリが必要です。この段階で、開発者は自分のコードを確認し、Firebase のアプリケーション処理インターフェース (API) と、コード内でそれをどのように呼び出したかを確認します。また、ユーザーを定義する変数を調べて、適切に定義され、機能が適切であることを確認します。また、使用されているライブラリや Firebase API リンク自体など、データベースへの接続を妨害または操作するものを更新する必要があるかどうかを確認することもあります。呼び出しを無視してデータベースの解決策を見つけるために、これらすべての手順またはそれ以上の手順を実行することができます。 1 つの問題があります。
これはどれも私には当てはまりませんでした。これはなぜですか?
これらの標準的なデバッグ方法を実行する必要がなかったのは、この新しい試みの少し前に、新しいユーザーをデータベースに登録できたからです。 1週間以内に、これは突然止まりました。コードを変更しないと、以前は機能していたプロセスが機能しなくなりました。これは私を大いに混乱させ、API 呼び出しリンクを繰り返し置き換えて、別の場所に配置しました。慣れ親しんだライブラリの参照呼び出しと、さまざまなファイル呼び出しを整理しました。 Firebase のデータベース サービスがダウンしているかどうかをオンラインで問い合わせることもできました。そうではありませんでした。それから私は標準的なデバッグの実践を始めようとしていました..そして、私はついに解決策を見つけました!それはずっと私のメールにありました。
はい、私のメールにはずっと解決策がありました!この問題で何日も停滞した後、メールを確認したところ、Firebase からの通知メールが見つかりました。 Firebase から、データベースへのアクセスが切断されたことが通知されました。これは、Firebase データベースのセットアップ中に、セキュリティ上の理由から特定の日付でデータベース アクセスを切断するようにセットアップしたためです。自分で追加したこのルールを忘れていました。指定した日付を忘れていました。その結果、メールをチェックするまで気がつかなかったのです。以下では、2023 年 3 月 12 日に私を切断するようにデータベースを設定したことがわかります。
この問題を解決するには、ルールを更新して「カットオフ」日の期間を延長する必要がありました。ここに見られるように:
この問題を解決するために、次の締め切りを 6 月 29 日に設定しました。このようにして、その締め切りまで再び中断することはありません。
「気にしないように、今から数年後または数か月後に設定してみませんか?」と尋ねる人がいるかもしれません。良い質問。この依存関係を思い出させるために、年間を通していくつかの四半期ごとのリマインダーが欲しいので、私はそれをしません.期限を長期に設定して、それをまた忘れて、1 年後に同じ状況で立ち往生したくはありません。頭の中で繰り返し意識するということは、アプリ開発に影響を与える可能性のあるすべての要因を常に考えているということであり、開発プロセスを進める上で役立ちます。これを学習の好みと呼ぶかもしれません。
Firebase Authentication プロシージャは、ユーザー ID トークンをユーザーの特別な識別子として返していることもわかります。これにより、登録されていることを確実に知ることができます。
開発は楽しいですが、常に小さなことを意識しなければなりません。ほとんどの場合、アプリケーションに問題がある場合、それは私たち自身のコード エラーが原因である可能性が最も高いです。ただし、コードから問題が発生しない場合もあります。必要な更新や、この場合は単純なデータベース ルールの見直しなど、実際には単純なものである可能性があります。