Markdownのメターデータの復旧処理

Markdownのメターデータの復旧処理

Firebase のデータベース Firestore に Markdown のメタデータを保存して管理している場合、Firestore のドキュメントを削除すると、見かけ状はファイルが無いように見えます。実際に Firebase のストレージに保存したファイルを削除せずに Web サービスの利用者から見えなくする事が可能です。この記事では、Firebase のストレージのファイルは触らずに、Firestore を利用して管理する場合の詳細を紹介します。

大切なバックアップと復旧処理

Markdown で書いた記事の原稿を、Firebase のストレージにおいて、Web 上で記事を公開する、ブログのようなサービスを提供する場合を考えてみます。 開発中などは、プログラムのバグなどで、データベースのデータを壊してしまうこともありますし、実際の運用でも、潜在的な不具合でデータベースが壊れれしまうことも考えられます。このような事態に備えてバックアップはひつようですが今回紹介している事例では、バックアップを簡単にすると同時に、復旧の方法も簡単に実装できます。

通常の Web サービスでは、基本的に Firebase のストレージのファイルの削除は行わないようにします。 こうすることで、何らかの理由で、Firebase のデータベース（Firestore)が壊れれてしまった場合の復旧を簡単に行う事ができます。 バックアップも、アップロード時にオリジナルのファイルを PC などに残しておけば、Web 上のデータはバックアップしないでも、データの復旧が可能になります。

あらかじめ、こうした不測の事態に備えておくと、サービスを停止しなければいけない時間は最小限に抑えることが可能になります。

メタデータを拡張する

Markdown に埋め込まれたメタデータは基本的に、記事の原稿などに関するデータが中心になります。 これに加えて、Web サービスを提供する上で必要なデータを追加して Firebase のデータベース（Firestore）に保存しておくと管理が楽になります。

今回のブログのサービスの例では、記事を表示するかしないかを示す「hide」というデータをメタデータに追加しておくと、表示と非表示の切り替えが簡単に行えます。

例えば、Markdown のメタデータには、

＊　title: 投稿のタイトル

＊　description: 投稿の概要

＊　date: 投稿日

のデータを埋め込んでおくとします。 これに加えて、Firebase のデータベースに「id」、「path」、「name」、「url」、「hide」の項目を追加して表示の管理をします。 データベースに保存する JSON は以下のようになります。

{

  "id": "原稿のID",

  "path": "Firebaseストレージのフォルダ名（bucket）",

  "name": "原稿のファイル名",

  "title": "投稿のタイトル",

  "description": "投稿の概要",

  "date": "2022-05-10",

  "url": "Firebaseストレージのファイルのリンク（URL）",

  "hide": false /* boolean: true: 非表示/false: 表示 */

}

このデータを Firebase のデータベース（Firestore）に保存します。

一般の利用者向けのファイルの一覧の表示には、「hide」が「false」のドキュメントのみを抜きして表示するようにします。 管理者向けの表示は、全てのドキュメントを表示して、「id」、「path」、「name」、「url」以外のデータは編集可能にしておくと管理が簡単です。

ここで、「title」、「description」、「date」を変更する場合には、オリジナルの Markdown のファイルの情報も更新した方が、データの復旧を考えると良い場合が多くなります。ただし、実装を簡単にするには、これらのフィールドも変更不可にしてしまって、更新したファイルをアップロードするようにすると、実装がシンプルになります。

このように考えると、実際に値を変更するのは、「hide」のみで十分という事になります。

表示の際に、「hide」の表示をクリックしたら、表示・非表示が入れ替わるように実装すると、簡単に変更ができます。

復旧の場合は？

次に、Firebase のデータベースが壊れてしまった場合を考えます。 復旧の方法は大きく二つです：

＊　Firebase ストレージのファイルを利用して Firestore のメタデータを再構築する方法

＊　オリジナルの Markdown の原稿ファイルを投稿前にバックアップしておいて、際アップロードする方法

殆どの場合は、Firebase ストレージのファイルを使えば復旧が可能です。これが、通常の処理では極力 Firebase ストレージのファイルに触らない理由です。

これは、以前に紹介したように

1. Firebase のストレージのフォルダ内のファイルの一覧（ストレージのリファレンス）を取得

2. Firebase のストレージのリファレンスからダウンロード用のリンク（URL）を取得

3. Markdown のメタデータを抽出（gray-matter などを利用）

4. id / path / name / url / hide を追加して、Firestore に保存するメタデータを作成　（hide はデフォルトで表示か非表示を選択）

5. Firestore にメタデータを保存

で、復旧できます。

オリジナルのファイルを使う場合には、通常のアップロードと同じなので、特別な処理は必要ありませんが、投稿の数が増えた場合にはファイルを一つ一つアップロードするのは面倒なので、まとめてアップロードする処理を作るか、Firebase コンソールからまとめてアップロードして、最初の方法で Firebase のデータベースに保存するメタデータを作るようにすると使いやすくなります。

バックアップの仕組みは？

今回の例では、特別にバックアップをする仕組みを作らなくても、投稿時のオリジナルデータを保存しておいて、そのファイルをバックアップすることで、直接 Firebase のデータベースをバックアップしないで済むような方法にしています。 Firebase のデータを直接バックアップする場合には、Firebase のデータベースにアクセスしてデータを取得した後に、JSON や表計算の形式でファイルに保存する処理が必要になります。

Firebase を利用して、フロントエンドのみの実装の場合には、作成したファイルをダウンロードするような方法で PC に保存する必要があります。これはセキュリティ上のリスクを少なくするため、通常の設定では、Web ブラウザで動作しているプログラムから PC などのファイルにアクセスする処理は制限されているためです。

まとめ

この記事では、Firebase のストレージに、Markdown で書かれた記事を保存して Firebase のデータベース（Firestore）を使ってメタデータを管理してブログなどのサービスを提供する場合に、Firebase のデータベースのデータが壊れた場合に、復旧を考慮した実装のコンセプトを紹介しました。 少し、処理が複雑になってきたので、コードの書き方を工夫しないと、コードの管理やデバッグが大変になる場合があります。次回の記事では、管理しやすいコードの書き方のコツを何回かに分けて紹介します。