「Firestore」の記事 - Crieit

自分の理想の教室を、友達とリアルタイムで一緒に作れるウェブサービス「みんなのきょうしつ」をリリースしました。

2020-06-05T22:29:21+09:00

さっき投稿した記事で、4日前に「musico」というウェブアプリをリリースしたことについて書きましたが、

好きな楽曲について語り合うウェブサービス「musico」を作ってみました。
https://crieit.net/posts/musico
musico | find track you like and talk about it

実は昨日、もう一つウェブアプリをリリースしましたｗ
その名も「みんなのきょうしつ」。

開発の動機

このアプリは、もともと３月のコロナ禍による一斉休校をきっかけに、いきなり会えなくなった友達とオンラインで再開して貰い、小中高生のみなさんに、社会の混乱からのストレスを一時的にでも忘れてもらえたら良いなという思いで、二日間ぐらいでガッと基本的な機能を作って公開しようとしていたものでした。ですが、その後なかなか着手する時間が取れず、限定的な公開にとどめて、ほぼ動いていない状態が続いていました。

開発頓挫、からの突貫リリースへ

そんななか、先日の「musico」の開発と公開をきっかけに、テンションとモチベーションがひさびさに爆上がりしたので、この機を逃す手はないと思い、一念発起して昨日・一昨日をかけて最低限の機能を実装し、公開していみました。

どんなアプリ？

このアプリでは、教室を模した座席表的なものに、自分の好きな人やモノの名前と写真を登録していき、自分の理想の教室が作れます。

さらに、URLを共有することで、別の場所にいる友だちとオンラインでリアルタイムで共同編集することが出来ます。（動画は開発中に撮影したものです）

動作ムービー

また、「記念撮影」機能で作った教室の画像を作成・ダウンロードしたり、各種SNSに手軽にシェアすることが出来ます。（写真は友人が作った「あつまれどうぶつの森」のキャラクターが集まる教室です）

https://class-room.fun/classrooms/8jVBr7suU0In1vbE3Ze8

地味にインスタ映えしたりしますｗ

技術的なこと

技術スタック的には「musico」と同じくFirebase+Vuejs（Nuxtjs）という、構成です。「musico」はUniversalモード（SSR）で作りましたが、こっちはSPAとして開発し、OGP取得部分のみCloud Functionsで作りました。

しかし、Firebaseめっちゃ便利ですね〜。

こっちもあんまり凝ったことはしていないのですが、OGPの動的生成あたりとか、記念写真機能あたりについて、あとで技術的なことを書こうかなと思っています。

それではまた。

Nuxt+Firebase Cloud Messaging(FCM)でWebプッシュ通知を送る

2020-05-24T17:18:35+09:00

WebでもFCMが使えるようになったので、試してみたときの備忘録。
これでSafari以外には、通知が送れるようになる(´ω｀)

【PR】これをつかって、こんなのつくりました！

こんな通知を受け取れます！

１週間でWebサービスを作るイベント web1weekへの投稿作品です！
よかったら、遊んでみてください(´ω｀)

■エアで投げ銭できるWebサービス「エア銭」
URL: https://air-money.netlify.app/

参考にしたサイトさま

Firestoreの簡易管理ツールをNuxt.jsでつくってみた

2019-10-30T21:18:16+09:00

Firestore、とっても便利ですが、Firebaseのコンソールがイケてないので、
ローカルで動かせる簡易の簡易ツールを作ってみました。Nuxt.js製です。

Firebase Admin SDKを使ってるので、秘密鍵を配置すればOK。
セキュリティルールの変更も不要です。

動いているところはこんな感じ。

GitHubで公開してます。ただ書きなぐりなので、ソースはイケてないです。。
まだα版くらいなので、機能は限定的です。。

memory-lovers/simple-firestore-admin: Simple Firestore Admin

なんで作ったか

Firestoreを使ったWebサービスを作ってみたところ、
ちょこっとしたDBの変更にもデータが多かったり、1ドキュメントのサイズが大きいと、
Firebaseコンソールだと重い感じに。。

いろいろ見ていると、Webサービスなどもあるのですが、
セキュリティールールを変えないといけないなど、設定がめんどくさいなと。。

なので、 設定が少なくて、軽い管理ツールがほしい、と思い、作ってみました。

できること

とりあえず、いま自分が必要な機能だけなので、最小な感じ。

コレクションの検索: collection().where().orderBy()
ドキュメントの更新: doc().update()
ドキュメントの削除: doc().delete()

使い方

1. インストール

インストールは、GitHubからクローンしてください。

$ git clone [email protected]:memory-lovers/simple-firestore-admin.git
$ cd simple-firestore-admin

3. 起動

Nuxt.js製なので、こんな感じでビルドと起動をしてもらえればOK。

# パッケージのインストール
$ npm install

# ビルド
$ npm run build

# 起動
$ npm run start

http://localhost:3000で起動するので、
ブラウザで操作できるようになります。

開発時のポイント: serverMiddlewareでfirebase-admin

開発時にハマったポイントとしては、
firebase-adminがNode.js上でしか使えなかったことです。。

当初はNuxtアプリから直接firebase-adminを呼ぼうとしていましたが、
Node.js上でしか扱うことができないことをあとから知り。。

Expressなどからだと呼ぶことができるので、
NuxtのserverMiddlewareを使って、
APIサーバ的なものを内部で持たせるようにしてみました。

serverMiddlewareの使い方はこんな感じ。

Express関連のコード

簡易化してますが、こんな感じのコードを、server/index.tsに配置

import { Request, Response } from "express";
import * as firestore from "./modules/firestore";

import bodyParser from "body-parser";
import express from "express";

const app = express();

// setup body-parser
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());

// select
app.post("/api/select", async (req: Request, res: Response) => {
  // firestore.collection("users").get()的な処理をする
  const result = await firestore.fetchSelect(req.body);

  res.send(result);
});

export default app;

nuxt.config.tsで設定

先ほど作成したserver/index.tsをserverMiddlewareとして利用するように設定

import { Configuration } from "@nuxt/types";

const config: Configuration = {
  serverMiddleware: ["~/server"],
};

export default config;

別にサーバを建てると、開発時にCORS対策でaxiosでproxyしないといけなかったりしますが、
serverMiddlewareを使うとそういった設定も不要に(´ω｀)

おわりに

とりあえず、必要な部分だけを作っただけなので、
バグもイケてないところもまだまだありますが、よかったら遊んでみてもらえれば。

memory-lovers/simple-firestore-admin: Simple Firestore Admin

Firestoreの管理画面作りたいな。。と思ったら、
こんな感じでserverMiddlewareを使うのが良さそうです(´ω｀)

こんなのつくってます!!

冒頭で話していた開発しているWebサービスです！
だいぶデータも増えてきたので、こういう管理画面が欲しくなってきました。。

積読用の読書管理アプリ『積読ハウマッチ』
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

参考にしたサイトさま

Nuxt.js(SPA)+FirebaseのWebアプリで初マイグレーションをしてけど、いろいろ失敗した話。。

2019-10-26T09:06:51+09:00

これはただの失敗談です。。役に立つかわからないけど、誰かの参考になるといいな。。

Nuxt.js+Firebaseで開発したWebサービスをリリースして2ヶ月目くらい。
サービス止めて、初マイグレーションしてときの失敗談です。

サービスを止めてやりたかったこと

いままではちょこっとした変更が多かったため、
サービスを止める必要なく、Nuxtアプリの更新だけで十分でしたが、
新しい機能を追加する際に、Firestoreのスキーマを変える必要が出てきました。

やりたいことは、
「 今までのデータを読み取って、別の形式に再構成する 」
という感じのことで、止めないとダメかなと。

メンテンナンスのときの手順

手順はこんな感じ。

メンテナンス画面に遷移するようにmiddlewareを変更
firestoreのルールを全部ブロックするように変更
スキーマ変更処理を実行
メンテナンス画面を解除し、hostingに最新版をアップロード
firestoreのルールをもとに戻す

ポイントとしては、

ページを移動したら、middlewareでメンテナンス画面に遷移する
クライアントから変更されないように、全部ブロックするルールに変更する

の2点くらい。

結果、かなりの失敗をしました。。

やらかした失敗と反省点

ダメだったのは以下の2点。

時間がかかりすぎ(予想5h以内→実際11h)
メンテナンス画面がちゃんと出ていなかった

1. 時間がかかりすぎ問題

一番の失敗は時間かかりすぎです。。
予想以上に時間が。。予想5h以内→実際11h

対象のスキーマが、

本 - 履歴 - ユーザ

多対多の関係を持つ構造を持っていて、
本を起点に履歴データの構造を変更するような処理だった。

規模としては、本の件数が47670ドキュメントで、履歴が58144ドキュメント。

実際に実行してみたところ、速度が上がったり下がったりで、
1時間に5000冊位な感じ。。これだけで10時間近く。。

振り返ってみて

やってみていくつか良くない感じだったなと。。
振り返ってみて、改善できそうなのは以下の2点な感じ。。

a. メンテナンスでは差分部分のみ反映する

全量を読み込んで、反映していたので、かなりの時間が。。

とはいえ、1日の変更であれば、そこまで多くないので、
事前に全量の変更を用意しておき、メンテナンスにしてから、
差分があるところだけを更新をするなどのほうが良かった気がしてる。。

次はそうしよう。。

b. 処理の並列実行

内部の処理もPromise.allを使ってない部分がいくつか。。

foreachで実行している部分を置き換えて、
並列実行にするだけでも改善されそうな感じ。。

この記事がわかりやすい感じだった。
- Node.js で Promise の直列実行と並列実行、同時実行数の制御 - Qiita

2. メンテナンス画面が出てない

メンテナンスをはじめてから、GoogleAnalyticsを見てると、リアルタイムユーザがちらほら。
終わってからも、メンテナンス画面じゃないとの報告もちらほら。。

Firebase Hostingにアップロードしてもキャッシュが残っているとだめだったもよう。。

振り返ってみて

振り返ってみて、改善できそうなのは以下の2点な感じ。。

a. PWAモジュールを使ってnetworkファーストで取得する

以下の記事の前半で書かれている通り、キャッシュ戦略を設定することで解決できそう。
・Nuxt.js(SPA)とFirebaseで強制リビジョン（バージョン）アップするならPWAモジュールを使おう - Qiita

b. Remote Configを使って切り替える

同じく上記の記事で書かれている通り、Remote Configを使うのが良さそう。
・Firebase Remote Config | Firebase

Remote Configの値によって、メンテナンス画面の表示を切り替えれるようにしておけば、
Firebaseのコンソール上での変更で、切り替えれるようにできる感じ。

まとめ

やってみてわかることも多いですが、なかなかつらい感じ。。

Firebase/Firestore関連の運用系の話はあまり見ないので、
とりあえず書いてみましたが、誰かの役に立てば。。

こんな方法もあるよ！こっちのほうがいいよ！などあれば、
コメントもらえるとうれしいです(´ω｀)

ほかの失敗談

以前にもこんなのを書きました。
初級向けの話が多いですが、実際にやってみての体験談的な話。
- Nuxt.js(SPA)+Firebaseで積読用の読書管理サービスを作ってみたときにハマったこと... - Qiita
- Firebaseで作ったWebサービスを3ヶ月運用してみて、ハマったこと・知っておきたかったこと - Qiita

こんなのつくってます!!

やらかしたWebサービスはこちら。。
積読用の読書管理アプリ『積読ハウマッチ』
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてください〜

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

Firebaseで作ったWebサービスを3ヶ月運用してみて、ハマったこと・知っておきたかったこと

2019-10-11T10:59:34+09:00

Nuxt.jsとFirebaseで作っていたWebサービスを7月末にリリースして、はや3ヶ月。。
RDB脳なのでFirebaseを使った開発でいろいろとハマった。。そのポイントを整理してみました。

Firebaseをはじめようとしている人の一助になれば。

Nuxt.js(SPA)+Firebaseで作っています！

以前、以下のような記事を書いたのですが、そのFirebase関連ぽいまとめです。
・Nuxt.js(SPA)+Firebaseで積読用の読書管理サービスを作ってみたときにハマったこと... - Qiita

前回同様、内容的にはドキュメントをよく読めば書いてあることばかりですが、
実際に運用したり、機能追加したりする時に、気づくので、手戻りが多く...
あらかじめ、知っていたら良かったなと思う点をまとめています。

Firebaseはとてもよいですが、RDBに慣れ親しんでいると、
思わぬところでハマったり、運用してみて初めて分かることが多い感じに。。

ハマったことが多いですが、かなりコストを抑えて作れていてすごい( ﾟдﾟ)!
というのが、Firebaseを使ってみた感想です♪

全体の構成はこんな感じ

SPAモードのNuxtアプリをFirebase Hositingにデプロイ
データベースはFirestore
OGP生成のためにCloud Function for Firebase+ImageMagic
OGP用のHTML生成でCloud Function for Firebase
外部APIを利用したいのでZEIT NOW経由でのAPIを用意

わたしはここでハマりました。。

FirestoreでORがつかえない

DBを扱っているとORが使いたくなりますが、Firestoreでは使えません。。
公式ドキュメントのここに書いてある制約事項。。

論理 OR クエリ。この場合は、OR 条件ごとに独立したクエリを作成し、アプリでクエリ結果を結合する必要があります。

シンプルなクエリだったら複数回呼べばよいだけなので、あまり問題ないのですが、
orderByやlimitと一緒に使うと困ります。。

開発している積読ハウマッチだとこの部分。

読書中→積読の順序で表示して、
各ステータスは更新日時の降順で表示し、
30件ずつで表示する

という感じの処理をしています。

ORが使えないので、

読書中を検索
結果が30件未満だったら、残り分、積読を検索

という感じでやっています。

Firestoreで別フィールドでの範囲指定+orderByが使えない

これもFirestoreの制約事項。。

複数のフィールドに範囲フィルタを適用するクエリ（前のセクションの説明を参照）。

公式ドキュメントだとこのあたり。
複数のorderByとかは使えるけど、where+orderByだとダメ。
・Cloud Firestore で単純なクエリと複合クエリを実行する | Firebase
・Cloud Firestore でのデータの並べ替えと制限 | Firebase

たとえば、積読ハウマッチだと

持っている人が10人以上の本を、
更新日時の降順で並び替える

とかができない。。

実際にやる場合には、

あらかじめ、持っている人が10人以上の本を別コレクションとして作成しておいて、
そのコレクションに対して、更新日時の降順で並び替える

という形で対応する必要がある。。

開発当初・リリース前では、あまり気にならない制約事項だったけど、
リリース後の機能追加などで制約に引っかかるように。。

ドキュメントフィールドの削除は`FieldValue.delete()`

公式ドキュメントにちゃんと書いてあるけど、
ドキュメントフィールドを削除したいときは、FieldValue.delete()を使わないといけない。。

雰囲気で使い始めたときは、nullをセットすると削除できると思ってて、
そのままnullがセットされてた(´ω｀)

更新するときは、`update`と`set({merge: true})`がある

公式ドキュメントをよく読むと書いてあるけど、更新する方法は2種類ある。

updateは、ドキュメント全体を置き換える
set({merge: true})は、一部のドキュメントフィールドを置き換える

set({merge: true})については、すこし解釈が違うけどこんなイメージ。

公式ドキュメントの説明では、こんな感じ。

ドキュメントが存在するかどうかわからない場合は、新しいデータを既存のドキュメントに結合するオプションを渡し、ドキュメント全体が上書きされないようにします。

たとえば、こんなドキュメントがあって、

{
  name: "Alice",
  age: 20
}

年齢を30歳に変えたいなと思った場合、こんな感じ。

const docRef = db.collection("user").doc("Alice");

// updateの場合、すべてのドキュメントフィールドを渡さないといけない
await docRef.update({ name: "Alice", age: 30 })

// set({merge: true})の場合、変更したいドキュメントフィールドだけ渡せばOK
await docRef.set({ age: 30 }, { merge: true })

間違えて、updateで変更したいドキュメントフィールドだけにすると。。

const docRef = db.collection("user").doc("Alice");

// updateの場合、すべてのドキュメントフィールドを渡さないといけない
await docRef.update({ age: 30 })

// => 
// {
//   age: 30
// }

こんな感じで、name: "Alice"が消えてしまいます。。

その名の通り、マージなので、新しいドキュメントフィールドを追加したいときにも便利(´ω｀)

const docRef = db.collection("user").doc("Alice");
await docRef.set({ bookNum: 0 }, { merge: true })

// => 
// {
//   name: "Alice",
//   age: 30,
//   bookNum: 0
// }

マイグレーションするときは、これを使って、フィールドを追加したりしている(´ω｀)

トランザクション内では最大500件まで

公式ドキュメントだとこのあたり。
・トランザクションと一括書き込み | Firebase

制約がいくつか書かれているけど、以下のな感じ。

トランザクション内では、書き込みよりも読み込みを先にしないといけない
トランザクションが最大リクエストサイズの10MiBまで
1度でできる書き込みは最大500のドキュメントまで

特に気になるのが、書き込みは最大500のドキュメントの部分。

何千件も更新しないといけない場合に、問題が発生してきます。。

5000件あると、10個のトランザクションに分ける必要がありますが、
たとえば、1000件目で失敗した場合、最初の500件のみ実行される状態でエラーに。。

そうなった場合、どこでエラーが起きたかを記録する仕組みがないと大変なことに。。

積読ハウマッチでは、ログなど既存の情報から復元することで対応可能でしたが、
エラーが発生した場合、そのログを残しておくなどの仕組みがあるとよいなと。。

バグがないように作るのは大事なのですが、バグが起こったときに、
リカバリできる情報や手段を用意しておくのも同じく大事。。

Firestoreトリガーは不整合を起こしやすい

Firestoreで変更があったら、Cloud Functionsを呼ぶCloud Firestoreトリガー。
特定パスのCRUDに応じて、処理を組み込めるので便利。
・Cloud Firestore トリガー | Firebase

ただ、トランザクションと同じ感じで、トランザクションが分断されるので要注意。。

クライアント側でトランザクションを使っていたとしても、
トリガーで起動するCloud Firestoreはトランザクションに含まれません。。

そのため、クライアント側で正常終了したと思っても、
Cloud Firestore側でエラーが起こると、全体として不整合が起こった状態になります。。

Firestoreトリガーを使うときは、
トランザクションを分けてもよい処理なのかをよく検討する必要があります。。

Firestoreのスキーマ変更が大変

Firestoreはドキュメント型のNoSQLで、NoSQLはクエリ志向のDBです。
そのため、クエリが増える・変わるとスキーマを変更する必要が出てきます。

たとえば、「〇〇の総数」みたいなのはドキュメントフィールドとして値を持たせる必要があり、
あとでほしいと思った時に、マイグレーションが必要になってきます。。

Firestoreには分散カウンタという便利なものがありますが、

次のコードは、分散カウンタを初期化します。
と記載されているとおり、値が0のドキュメントフィールドが必要だったり。。

なので、ローカルPCでfirebase-adminを実行して、
Firestoreのデータを変更する仕組みを用意しておく必要があります。

ローカルPCでfirebase-adminを実行するときの話はこちらの記事に。
・ローカルPCからfirebase-adminを使ってFirestoreを操作する(管理ツール)
・ローカルPCでfirebase-adminを使って一括削除/一括更新する - Qiita

ただ、ドキュメント数が1万とかだと、
あっという間に無料枠を使い切るので、頻繁な変更は要注意。。

(とはいえ、1日に2万件の読み込みが無料だったり、)
(10万件ごとに$0.18/20円くらいなので100万件でも200円くらい。)
(RDBで100万レコードを扱うよりも、安い気がしてきている)

おわりに

わりとネガティブな内容になっている気もしますが、
制約を制約として認識していれば、問題ない話ばかりだと思ってます。

大変だったのは手探りでやっていたため、後で知ることになったため。。
設計とかする前に知っておきたかったまとめです。。

個人的にはFirebaseはとてもよく、
かなりコストを抑えてサービスを公開できてすごい( ﾟдﾟ)!
というのが、Firebaseを使ってみた感想です♪

気をつけることも多いですが、慣れれば大丈夫(´ω｀)
とはいえ、プロダクトによっては合わないこともあるので、なにかの参考になれば！

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ
機能追加が増えると知見も貯まるので、貯まったらまた記事を書こうと思います♪

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

Nuxt.js＋Firebase＋GAEで作った個人サービスが半月で2万PV超えたので実績値を全て公開する

2019-10-04T17:10:28+09:00

Qiitaへ投稿した記事のクロス投稿になります。

こんなサービス作りました

【#拡散希望】🙌🎉🎊サービス開始🎊🎉🙌ボケをツイートして「いいね❤️」「リツイート🔁」の数でランキング！Twitter連動型大喜利サイト「ついぎり」サービス開始しました‼️#ついぎり https://t.co/bkXfzHyVSs
— ついぎり@公式アカウント (@twigiri_app) August 14, 2019

Twitterで大喜利するサービスです。
８月中頃にローンチしたのですが、有難いことに半月で約2.5万PVいきました。

開発に至ったポエム記事はCrieitに投稿しています。
なぜ大喜利サービスを作ったのか

この記事について

やっぱり公開直後は怖かったです。

そう、クラウド破産。
Firebaseの設定を間違えて72時間で300万円以上請求されてしまったウェブサービス
 BigQueryで150万円溶かした人の顔

上記以外にもネット上にはインパクトのある高額請求の記事がたくさんあり、
内容を確認すれば「なんだそんな事か」となるのですが、
実績値というのはセキュリティやNDAの関係からか、なかなか出回ってません。

個人開発ならそんなの関係ねぇ

って事で全て公開します。
使い方によって大きく変わる所かと思いますが、何かの参考（個人開発の後押し）になれば幸いです。

環境構成

Nuxt v2.8.1
- SSRモード
GAE
- standard
- runtime: nodejs10
- instance_class: F1
Firestore
- 改めて別記事書こうと思いますが一般的な構成だと思います
Cloud Functions for Firebase
- engine: node8
- ユーザー登録/脱会/ツイート/いいねRT集計/バックアップで使用
Cloud Storage for Firebase
- OGP画像の保存に使用
Regionは全てasia-northeast1

使用量

PV数

トータルで約2.5万PV。
デイリーだとローンチ直後の約5,500PVがMAXです。

割り当て

アクセス数に比例した増加は見られませんでした。

GCP Storage egress between NA and APAC
使用量: 3.59GB
一番費用が発生してるこれ、よく分かってません・・・
GAEのデプロイにかかる項目なのかな？と思ってます。

Cloud Firestore Entity Writes Japan
Cloud Firestore Read Ops Japan
Write: 480,077
Read: 606,253
Firestoreは1日単位で無料枠がリセットされるのですが、リリース直後はちょっと無料枠から足出た程度ですね。
21日辺りは障害等でデータいじってた・・・気がします。

諸経費

サーバー代

0円でした。
使用量として57円かかってるのですが、
GCPには1年間有効な$300のトライアルクレジットがあるので、そこに収まってます。
クレジットを$0.5消費しました。使い切れる自信がありません。

ドメイン代

1,600円です。
Google Domainsでappドメインを取りました。
appドメインはSSL証明書無しでは使えないという安全なドメインです。
GAEの場合、SSL証明はデフォルトで有効＆無料です。

収益

AdSense広告を導入しています。
キャプチャは載せて良いのか分からなかったので・・・
半月で約1,300円でした。

所感

環境構成について

一番びっくりしたのはNuxt.jsがF1インスタンスで落ちずに稼働していることです。
公式ドキュメントでもF2が推奨されてるのですが、F2では無料枠に収めることが難しいです。
バックエンド処理をFirebaseに任せてるおかげで負荷が少ない構成になってるのかなーと思います。

費用について

正直「バズった」と言える数値ではないと思ってるので「バズっても大丈夫」とは言えないです・・・
座布団数(ボケツイートのいいね/RT総数)も、現在のランキング1位は3桁です。
「バズっても大丈夫」と分かったら改めて記事書くので、誰かバズってください。

しかし、まぁバズが発生してない個人開発としてはそれなりのアクセス数だと思ってます。
それで数十円なので「そんなに怖くないよ！」とは言えるかと。

安心して使うために

GCPの課金アラートを設定する
Rulesはちゃんと書く

は最低限やっとくべきです。
ただ、Rulesはちゃんと書くと一般的なバックエンド処理と同レベルの規模になると思います。
最低限の尺度が難しいですが、認証/取得件数/タイムスタンプ比較辺りは最低でもやっておくべきです。

マネタイズについて

AdSenseに頼ったサービスの運営は凄く難しいという体験をしました。
PV落ちたら施策を打たないといけないので放置出来ないし、
収益率はAdSenseの匙加減１つで大きくブレそうです。

前作ではマネタイズしてなく、正直「もしバズったらお金かかるよな・・・」とアクセス数に対してネガティブになってました。
その経験を踏まえ、広告を貼りました。
結果、素直に「バズれ！」と思えるようになったので、それだけでも導入した価値はあったかと思います。

おわり

今後、この個人開発で得た知見で記事書こうと思ってます。

TwitterAPIがBANされた話
Firestoreの構成について
文字入れ画像を作るソースコード
オレオレアトミックデザイン

他に「ここ知りたい」等あれば公開しますし、ボリュームある内容であれば記事書きます！

ただ、一番書きたいのは「バズっても大丈夫だった件」です。

Twitter連動型大喜利サイト「ついぎり」

面白い投稿お待ちしてます😋

複数のプロジェクトのfirebase-adminを起動して、開発用に本番データの一部を移行する

2019-09-26T19:11:16+09:00

開発しているWebサービスで、本番データの一部を開発用に使いたいと思ったときの備忘録。
firebase-adminは複数のプロジェクトで使えるらしい。

開発用だけじゃなく、UIDを変更しながらのデータ移行などにも使えそう。

ローカル環境でfirebase-adminを使うための準備

準備の部分は、以前まとめたこちらを参照ください〜
- ローカルPCからfirebase-adminを使ってFirestoreを操作する(管理ツール) - くらげになりたい。

ソースはこんな感じ。

const admin = require("firebase-admin");  

// *** 移行元のプロジェクトの設定
const srcSA = require("./key/XXXXX.json");   // サービスアカウントの秘密鍵を取得
// firebase-adminの初期化
admin.initializeApp({ credential: admin.credential.cert(srcSA) }); 
const srcDB = admin.firestore();          // firestoreのインスタンスを取得

// ** 移行先のプロジェクトの設定
const destSA = require("./key/XXXXX.json");  // サービスアカウントの秘密鍵を取得
// ※同じadminを使って、別のAppを作成しないといけない※
// ※2つ目を初期化する場合は、"dest"など名前をつけないといけない※
const destAdmin = admin.initializeApp( { credential: admin.credential.cert(destSA) }, "dest");
const destDB = destAdmin.firestore();        // firestoreのインスタンスを取得

// ****************************
// * MAIN
// ****************************
async function main() {
  console.log(`***** START MAIN`);

  // 移行元からデータを取得
  const snaps = await srcDB.collection("data").get()
  const srcData = snaps.docs;

  for (let v of data) {
    try {
      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      await destDataRef.set(v.data());
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

  console.log(`***** END   MAIN`);
  process.exit(0);
}

main().then();

雛形はこんな感じ。

以前書いた以下の記事だと丸々移行するので、UIDが変わるとめんどくさいことになる。。

この方法であれば、

whereで一部のだけに絞り込んだり、
set()するときに、UIDを差し替えたり

できるので、開発用に使うにはよいかんじ。

注意1: 2つ目を初期化する場合は別の名前に

そのまんまコピペで2つのfirebase-adminを作るとエラーに。。
2つ目を初期化する場合は、"dest"など名前をつけないといけないいけないらしい。。

公式ドキュメントの「複数のアプリを初期化する」に書いてあった。

これで、2つのfirebase-adminが起動できるので、データ移行などもできそう(´ω｀)

注意2: メモリを大量に使いそうな場合はオプションを指定

データが多く、メモリを大量に使いそうな場合は、
--max_old_space_sizeオプションを指定しないといけない。。

途中で失敗すると(読み込み/書き込み件数的に)悲しいことになるので、
大きめのサイズを指定しておくと良さそう。

node --max_old_space_size=8192 index.js

注意3: 件数が多い場合は、limitを指定して再帰処理

大量のデータを一度に取得しようとすると、

Deadline Exceeded error

が出て怒られるので、少しずつ実行するのがよいかんじ。

const BATCH_SIZE = 300
async function moveData(lastItem) {
  // 移行元からデータを取得
  const colRef = srcDB.collection("data");
  let query = colRef.orderBy("createAt", "asc");
  if (lastItem != null) query = query.startAfter(lastItem.createAt);
  const snap = await query.limit(BATCH_SIZE).get();

  if (snap.docs.length === 0) return; // 0件なら終了する
  const srcData = snaps.docs;

  for (let v of data) {
    try {
      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      await destDataRef.set(v.data());
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

  // 最後の要素を渡して、そこから継続する
  await moveData(data[data.length - 1]);
}
// ****************************
// * MAIN
// ****************************
async function main() {
  console.log(`***** START MAIN`);

  await moveData(null);

  console.log(`***** END   MAIN`);
  process.exit(0);
}

注意4: 複数の場所に反映する場合は、batchやtransactionを使う

途中でエラーになる場合もあるので、batchやtransactionを使うとよさそう。

公式ドキュメントだと、このあたり
- トランザクションと一括書き込み | Firebase

  for (let v of data) {
    try {
      const batch = destDB.batch();

      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      batch.set(destDataRef, v.data());

      // 移行先からデータを保存: その2
      const destData2Ref = destDB.collection("data2").doc(v.id);
      batch.set(destData2Ref, v.data());

      // コミット
      await batch.commit();
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

ループ外で使うほうのもいい感じ。

ただ、一括で書き込めるドキュメント数は500までと制限があるので、
一度に書き込む範囲は適宜調整が必要。

1 回のトランザクションまたは一括書き込みでは、
最大500のドキュメントに書き込みを行うことができます。
トランザクションと一括書き込み | Firebase

まとめ

firebase-adminは複数のプロジェクトでも扱える。
部分的なデータ移行や一部を書き換えながらの移行もできる(´ω｀)

ただ、件数が多かったり、複数の書き込みがある場合は、いろいろ必要。。

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

Firestoreのデータを分析するための3つの方法とその注意点

2019-09-24T20:45:37+09:00

別の記事を書く前に、いろいろ試したことの備忘録。
Firestoreのデータをいろいろ見たかったけど、
別プロジェクトの移動してみることにした経緯のまとめ。

試したのは以下の3つ

エクスポートデータをBigQueryにインポートしてBigQuery上で確認
node-firestore-import-exportを使ってローカルのJSONファイルとしてエクスポートして確認
別プロジェクトにデータを移行して、別プロジェクト上で確認(この記事)

それぞれの方法と注意点は以下の通り。

1. BigQueryにインポートして確認

公式ドキュメントなどで紹介されている通り、
FirestoreのデータをBigQueryにインポートできるらしい。

これが一番いい方法だが、後述するカラム10000制約に引っかかったので、諦める形に。。

流れとしては、こんな感じ。

バックファイルファイルを配置できるようCloud StorageにBucketを作成
gcloudを使って、Firestoreのバックアップファイルを作成したBucketにエクスポート
BigQueryでデータセットを作成
テーブルを作成する際に、テーブル作成元に「Google Cloud Storage」を選択

注意: ハマった点

a. バックアップデータを作成する際は、collection-idsを指定しないといけない

公式ドキュメントにも書いてあるが以下の通りらしい。。

エクスポートコマンドには、collection-idsフィルタを指定する必要があります。
コレクションIDフィルタを指定せずにエクスポートされたデータをBigQueryに読み込むことはできません。

なので、バックアップする際は、こんな感じで、コレクションを指定しなければならない。

$ gcloud beta firestore export gs://[BUCKET_NAME] --collection-ids=[COLLECTION_ID_1],[COLLECTION_ID_2]

b. ファイル形式も「Cloud DataStoreバックアップ」に変更しないといけない

公式ドキュメントのスクリーンショットになかったのでハマった。。

インポートする際には、ファイル形式も「Cloud DataStoreバックアップ」に変更しないといけないらしい。。
なにもしていないと、ファイル形式「Avro」になっているので、ファイル形式が合わずエラーになってしまう。。

c. ドキュメントフィールドがobjectの場合、ドット区切りで展開され、カラムの上限は10000まで

これが原因で諦めました。。

Firestore上で、以下のようなobjectやマップなどが存在すると、

{
  "uid": "XXXXX",
  "group": {
    "groupA": true,
    "groupB": false
  }
}

BigQueryにインポートする際、ドットで繋げる形で展開されます。

uid, group.groupA, group.groupB

また、公式ドキュメントの制約事項に、

Cloud Firestore のエクスポートを正しく読み込むには、
エクスポートデータ内のドキュメントが一貫したスキーマを共有し、
個別のフィールド名が10,000個未満でなければなりません。

と、あるため、大量のプロパティを持つobjectをセットしていると、インポート時にエラーになります。。

対応策

フィールド数の問題を回避する方法として、特定のフィールドだけ読み込むこともできます。

CLI で --projection_fieldsフラグを使用するか、
load ジョブの構成でprojectionFieldsプロパティを設定することで
特定のフィールドを読み込むことができます。

とあるため、読み込むフィールドを指定することで、回避することができそうです。

2. node-firestore-import-exportでローカルにエクスポート

次にやったのがこれ。
node-firestore-import-exportを使うと、CUIでJSON形式でエクスポートできるらしい。
JSON形式でエクスポートできれば、ツールなど作っていろいろできそうかなと。

実行するには、Google Cloudアカウントのcredentialsファイルが必要。

# インストール
$ npm install -g node-firestore-import-export

# 全体のバックアップ
firestore-export --accountCredentials path/to/credentials/file.json --backupFile backups_myDatabase.json

# コレクションを指定して、一部だけをエクスポート
firestore-export --accountCredentials path/to/credentials/file.json --backupFile backups_myDatabase.json　--nodePath collectionA

データ量が多い場合は、--max_old_space_sizeを指定して実行する。

node --max_old_space_size=8192 /usr/local/bin/firestore-export --accountCredentials path/to/credentials/file.json --backupFile backups_myDatabase.json

注意: というか見送った点。。

サクッと使えてよかったけど、データ量が多いと、やはりつらい。。

データ量が多いと、メモリ不足やFirestoreとのコネクション切れで失敗する
無料枠でも使えるが、firebase-adminを使って取ってきているだけなので読み込みが大量に発生する
エクスポートしたファイルも大きくなるため、ツールでもメモリを大量に使う

別プロジェクトにデータを移行して、別プロジェクト上で確認

上の2つの方法を試してなんとかしたかったのは、このの3つ。

エクスポート時に大量の読み込みが発生し、本番環境の無料枠を消費する
ネストが深いobjectがあるとと簡単にBigQueryにインポートできない
ローカルファイルでも全データをメモリ上に展開するので、つらい

そのため、別プロジェクトに移行して、本番環境と関係ない部分で、いろいろ触れるようにしてみた。
これであれば、本番環境を気にせず、firebase-adminとかで、いろいろ調べたりできそう。

詳細なやり方は、別の記事にまとめました。

他と同様、リアルタイムの情報ではないので、注意が必要。

簡単なまとめ

1. BigQueryにインポートして確認

BigQuery上なので、SQLで分析ができる
有料プランのみ
注意: バックアップデータを作成する際は、collection-idsを指定しないといけない
注意: ファイル形式も「Cloud DataStoreバックアップ」に変更しないといけない
注意: ドキュメントフィールドがobjectの場合、ドット区切りで展開され、カラムの上限は10000

2. node-firestore-import-exportでローカルにエクスポート

無料枠でも使える
JSONでエクスポートできる
注意: エクスポート時に大量の読み込みが発生し、本番環境の無料枠を消費する
注意: ドキュメントのネストが深いと簡単にBigQueryにインポートできない
注意: ローカルファイルでも全データをメモリ上に展開するのでつらい

3. 別プロジェクトにデータを移行して、別プロジェクト上で確認(この記事)

有料プランのみ
別プロジェクトなので、本番環境を気にせず使える

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで

参考にしたサイト

Firestoreのデータをgcloudを使ってバックアップ＆別のプロジェクトへインポートしてみる

2019-09-24T19:17:59+09:00

Firestoreのデータをガリガリ見ていきたいなと思っていたら、
別のプロジェクトに移行できそうだったので、いろいろ調べたときの備忘録。

分析目的だけど、BigQueryは1000カラム制約で使えなかったので代替案...
別プロジェクトなら無料枠でいろいろできそう。

注意

Firestoreのエクスポート/インポートについて、いくつか注意。

Firestoreのエクスポート/インポートはBlazeプランが必要(無料枠では不可)
ドキュメントの読み取りと書き込み時にCloud Firestoreの料金が課金される

さらに、

エクスポート / インポートオペレーションのコストは、費用制限の対象にはなりません。
オペレーションが完了するまで、エクスポート/インポートでGCPの予算アラートはトリガーされません。

とのことなので、ご利用は計画的に..

1. gcloudのインストール

インストール

$ brew cask install google-cloud-sdk

.bashrcなどに以下を追記

source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc'
source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc'

gcloudの初期化

# 初期設定の実行
$ gcloud init
# このあと、ログイン画面が出てきて認証する

# コンポーネントのアップデート
$ gcloud components update

# 現在のプロジェクトの確認
$ gcloud info | grep project

2. FirestoreのデータをExportする

firestore exportを使うと、データのバックアップが作成できるらしい。
バックアップデータはGCPのStorage上に作成されるので、
あらかじめ、Storageを作成しておく必要がある。

# 現在のプロジェクトの確認
$ gcloud info | grep project

# 全体のエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME]

# コレクションを指定して、一部だけをエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME] --collection-ids=[COLLECTION_ID_1],[COLLECTION_ID_2]

# 実行状況の確認
$ gcloud beta firestore operations list

データ量が多いと、コマンドが途中で終了するので、
完了したかどうかはoperations listを実行して確認する必要がある。

参考: データのエクスポートとインポート | Firebase

3. プロジェクトを変更する

# プロジェクトの設定
$ gcloud config set project [PROJECT]

# 現在の設定情報の確認
$ gcloud info

参考: SDK 構成の管理 | Cloud SDK のドキュメント | Google Cloud

4. アカウントを変更する

# アカウントの設定
$ gcloud config set account [ACCOUNT]

# 設定したアカウントの認証
$ gcloud auth login

# 登録しているアカウントの一覧を確認
$ gcloud auth list

# プロジェクトの設定
$ gcloud config set project [PROJECT]

# 現在の設定情報の確認
$ gcloud info

参考: Cloud SDK ツールの承認 | Cloud SDK のドキュメント | Google Cloud

5. バックアップを別のプロジェクトにインポートする

全体の流れはこんな感じ。

# バックアップしたいプロジェクトに設定
$ gcloud config set project [PROJECT]

# 全体のエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME]


# 別のプロジェクトにプロジェクトに変更
$ gcloud config set project [PROJECT]

# バックアップファイルのインポート
$ gcloud beta firestore import gs://[BUCKET_NAME]/[EXPORT_PREFIX]/

注意点

インポートしたいプロジェクトのFirestoreは初期設定までする必要がある
実行はプロジェクトのサービスアカウントで実行されるので、
バックアップファイルのバケットに権限を付与する必要がある

参考: データのエクスポートとインポート | Firebase

おわりに

有料のみではあるけど、

本番データの分析したり
本番データを開発用に利用したり
プロジェクトの移行

なんかにも使えそう。
分析はBigQueryを使えるならそのほうがいいかも？

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで

参考にしたサイト

ローカルPCでfirebase-adminを使って一括削除/一括更新する

2019-08-16T12:23:37+09:00

最近、Nuxt.js+Firebaseで作った積読を解消するWebアプリ「積読ハウマッチ」をリリースしました！！

そのときに、Firestoreのスキーマを一括変更したり、
不要なデータを一括削除したいと思ったときの備忘録。

ローカルPCでfirebase-adminを使うときの初期設定とかはこちらを参照
- ローカルPCからfirebase-adminを使ってFirestoreを操作する(管理ツール) - くらげになりたい。

注意点

Firestoreでは、1度に実行できる更新処理の数に制限がある。

一括書き込みでは最大 500 件のオペレーションを実行できます

トランザクションと一括書き込み | Firebase

そのため、以下にも記載されている通り、
100件ごとなど、小さなバッチに分けて実行する必要がある。

メモリ不足エラーを避けるため、小さなバッチに分けてドキュメントを削除することをおすすめします。コレクション全体またはサブコレクションが削除されるまで、このプロセスを繰り返します。

Cloud Firestore からデータを削除する | Firebase

小さなバッチに分けて実行するソース

全体としてはこんな感じ。

登場する3つ

main() ... メイン関数。実行したときに呼ばれる関数
deleteAllUsers() ... ユーザを一括削除する関数。mainから呼ばれる
executeBatch() ... 指定したバッチサイズで再帰的に実行する関数。deleteAllUsers()から呼ばれる

なお、コレクションusersのなかにあるドキュメントには、
作成日時のタイムスタンプcreateAtのドキュメントフィールドがある想定です。

const admin = require("firebase-admin");

// 配置したサービスアカウントの秘密鍵を取得
const serviceAccount = require("./key/XXXXX.json");

// firebase-adminを初期化
admin.initializeApp({ credential: admin.credential.cert(serviceAccount) });

// firestoreのインスタンスを取得
const db = admin.firestore();


/**
 * 一括実行処理の共通関数
 * @param {FirebaseFirestore.Firestore} db firestoreのインスタンス
 * @param {Number} limit 1回に実行するサイズ
 * @param {Function} queryFunc ドキュメントを検索するクエリを作成する関数。firestore.Queryを返す
 * @param {Function} executeFunc 削除や更新などを実行する関数。
 * @param {Object|undefined} last 検索でヒットした最後の要素。バッチサイズで繰り返す際に利用s
 */
async function executeBatch(db, limit, queryFunc, executeFunc, last) {

  // queryFuncを使って対象のドキュメントを取得
  const query = queryFunc(db, last);
  const items = await query.limit(limit).get();

  // ドキュメントが1つも見つからなければ、終了
  if (items.size === 0) return;

  // executeFuncを使ってbatchに削除/更新処理を追加＆コミット
  const batch = db.batch();
  for (let i = 0; i < items.size; i++) {
    executeFunc(db, batch, items.docs[i]);
  }
  await batch.commit();

  // リストの最後の要素を取得して、再帰実行
  const lastItem = items.docs[items.size - 1].data();
  return await executeBatch(db, limit, queryFunc, executeFunc, lastItem);
}


/**
 * すべてのユーザを削除
 */
async function deleteAllUsers(db, limit) {
 // 検索部分の関数: 作成日時で昇順ソートして取得
 const queryFunc = (db, last) => {
    let query = db.collection("users").orderBy("createAt", "asc");
    if (!!last) query = query.startAfter(last.createAt);
    return query;
  };

  // 実行部分の関数: itemで該当のドキュメントを受け取るので削除
  const executeFunc = (db, batch, item) => {
    const docRef = db.collection("users").doc(item.id);
    batch.delete(docRef);
  };

  return await executeBatch(db, limit, queryFunc, executeFunc, undefined);
}

// ****************************
// * MAIN
// ****************************
async function main() {
  console.log(`***** START MAIN *****`);
  // バッチサイズを100件で実行
  const limit = 100;
  await deleteAllUsers(db, limit)
  console.log(`***** END   MAIN *****`);
}

main().then();

他の処理でも共通的に使えるようにexecuteBatch()では、
queryFuncとexecuteFuncの2つの関数を引数で受け取れるようにしている。

なので他の処理などを追加するときは、deleteAllUsers()みたいなのを増やしていけばOK!!

これで一括削除やスキーマの更新もだいぶ楽に...(´ω｀)

おわりに

Webサービスは運用しはじめると色々大変なので、管理ツールなども大事...
最近リリースしたこちらのアプリでも使ってます♪

■積んでる本の総額がわかる読書管理サービス
積読ハウマッチ

総額がわかると少しは積ん読してる本を読もうと思ったり♪
積読総額ランキングや人気の本などもあるので、よかったらあそんでもらえれば!!

積読ハウマッチは、Nuxt.js+Firebase+ZEIT Nowで作ってます♪

参考にしたサイト

積読を解消をうながすWebサービス『積読ハウマッチ』をリリースしました!!!

2019-08-09T08:49:16+09:00

4月くらいから作っていたWebサービスをついにリリースしました♪
積んでる本の総額がわかる読書管理サービスです！

積読が多い自分を戒めるためのWebサービス( ﾟдﾟ)!

■積んでる本の総額がわかる書籍サービス｜積読ハウマッチ
https://tsundoku.site

思いついたときのツイート

思い返すと、完全にネタ的なおもいつきではじまった感(´ω｀)

おもしろそうなアプリを思いついてしまった。。自分がダメージを受けるが作りたい。。
— きらぷか📚積読ハウマッチ開発中【事前登録はじめました】 (@kira_puka) April 12, 2019

ちなみに、おもしろそうっていうのは、「くだらない！！」的なおもしろさで、すごい！とかイケてる！とかはまったくない
— きらぷか📚積読ハウマッチ開発中【事前登録はじめました】 (@kira_puka) April 12, 2019

こんなサービスです

メインの画面はこんな感じ。
本を登録して、ステータスを変更していく、積読を管理するサービスです。

ほかとちがうのは、本の総額がわかるところ
いま、いくら積んでいるかがわかってしまうおそろしさ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸ

コンセプト

おもいつきではあるんですが、もともと積読が多いなと。。

本で買うのですが、積み上がっている本を見て、ふと、
**「これっていくらなんだろ？」 **
とおもったのが発端。読まないとお金を積んでるだけだなと。。

使い方のかんたんな説明

使い方はシンプル

検索して、

持ってる本を積んで、

総額を見て、現実を受け止め、

積読を減らすことをがんばる！

持ってる本を登録して、読みはじめたり、
読み終わったりしたらステータスを変える感じです！

積んでる金額を見るだけだとつらいので。。

ランキング機能もついています(´ω｀)

「こんなに積んでるけど、ほかのひとはどれくらいなんだろ？」

っていうのが発端。

他の人のをみて「まだまだ積んでも大丈夫(´ω｀)」と思いたいなと。。

読まれてる本、買われてる本のランキングもあるので、
どんな本が人気かもわかるように♪

新着もあるので、新しく積まれたり読まれたりした本を、
ぼーっとながめるのも楽しい感じに(´ω｀)

Twitterでシェアして積読金額を晒せる...

SNSでシェアした時の画像も力をいれてみました(´ω｀)
積んでる金額を晒すと、さらに読まないといけない感が出るかも(・・?
(積んでるのに、ドヤ顔のおじさんが...)

もちろん、読んだ本も共有できるので、
「こんなに読んだんだ！がんばった！」
もシェアできます♪　独学や自己研鑽をがんばってるひとにも！

(こっちはすっきりしたおじさん...)

まだまだ作れてないところはたくさん。。

とりあえず、ファーストリリースができたんですが、
まだまだ作りたい部分はたくさん。。!!

読んだ感想やメモを記録できるようにしたい
どれくらい読んだかを日々の進捗を記録できるようにしたい
読み終える目標の日を決めて、アラートしてもらいたい

積読の消化を促すような機能をどんどんいれれたらとおもっています！

見てるだけでも楽しいので、まずはちらっとみてもらえたら♪
おもしろそうだなと思ったら、ぜひ一緒に積み比べしましょう！

良い積読ライフを(´ω｀)

■積んでる本の総額がわかる書籍サービス｜積読ハウマッチ
https://tsundoku.site

Nuxt.js+Firestoreの場合に安全にSSRする方法

2018-12-16T23:27:12+09:00

Nuxt.jsをサーバーで動かしてFirestoreを使い、且つサーバーサイドレンダリングしたい時には色々考えることが出てきます。懸念点と対応した方がよさそうな点をまとめてみます。

SSRしない場合との違い

SSRせずクライアント上でFirestoreからデータを取る場合ですが、匿名認証にしろ、SNSアカウントの認証にしろ、認証しているかどうかでセキュリティルールによりデータを守りやすく、他者によるFirebaseプロジェクトの設定を盗用しての勝手な操作を防いだりすることができます。

しかし、asyncData内によるSSRとなると、そのクライアント側の認証情報を利用することはできません。そうなるとデータを守れないどころか、そもそもセキュリティルールが設定されているとデータにアクセスすることすらできません。こういう時にどうすれば良いかを考えます。

どのように解決するか

Cloud Functionsの利用

今回はCloud Functionsを利用する方法を考えました。具体的にどうするかというと、asyncData内ではfunctionsからデータを取るだけにします。例えば下記のような感じです。

  async asyncData({ params }) {
    const response = await axios.get(functionUrl)
    return response.data
  }

呼び出し方はどうであれ、通信が発生するので上記のようにリクエストは１回にした方が良いでしょう。functions側でそのページ専用のアクションを作ってデータを返します。

export const showUser = functions.https.onRequest((req, res) => {
  return cors(req, res, async () => {
    const user = await User.getUserByUsername(req.query.id)
    res.json({
      user,
      posts: await Post.getPosts(user.uid, 5)
    })
  })
})

データの取得方法

しかし、これでは先程のasyncDataと同様、セキュリティルールの関係でデータが取れないのでは？　と思われるかもしれません。ただ、Firebaseにはサーバー用のFirebase Admin SDKというものがあります。これはセキュリティルールに関係なくデータを扱うことができるため、これを利用します。具体的には下記のような形です。

import * as admin from 'firebase-admin'

const firestore = admin.firestore()
const usersCollection = firestore.collection('users')

export async function getUser(uid: string) {
  const querySnapshot = await usersCollection
    .where('uid', '==', uid)
    .get()
    .catch(error => {
      console.error(error)
      return null
    })

  if (!querySnapshot || querySnapshot.size == 0) {
    return null
  }

  const user = querySnapshot.docs[0].data()
  user.id = querySnapshot.docs[0].id
  return user
}

クライアント側とは微妙にcollectionの取り方が違うだけで、基本的にはほぼ同じです。このようにしてサーバーサイドレンダリングのためのデータ取得処理を行うことができます。

セキュリティルールを無視で良いのか？

今回の例のfunctions側でのデータ取得処理に関しては、ルールを無視で問題ありません。

というのも、そもそもSSRの目的としては、クローラに認識してもらうためのSEO対策になるかと思います。つまり、ユーザー認証が必要なデータを取る必要は一切無いということになります。あくまでも誰もが閲覧できるパブリックなデータを取るだけです。そのため基本的には認証に関するセキュリティルールをこの場で考慮する必要はありません。ただ、corsはちゃんと挟んでおきましょう。

まとめ

やってみて思いましたが、これって普通のサーバーを使った開発と同じですよね！？　なんとなく手軽さが失われた感じはありますが、それでもまあサーバーを管理する必要が無いのは大きなメリットではあることに変わりはないでしょう。

他にも色々と方法はあるかもしれませんが、とにかくどの様な方法にしろ、どのようにデータを守るかはしっかり考えて構築が必要となります。

以前認証とセキュリティルールについて書いた考察もありますので、もし気が向いたらそちらもぜひ御覧ください。

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

RDBとFirebaseのDB両方使ったっていいじゃない

2018-11-27T21:41:07+09:00

今年Firebaseを使い始めてからちょこちょこ自分の中で議題に上がるのが、RDBとFirebaseのデータベース（Firestore、Realtime Database）のどちらが使い勝手良いのか、ということ。ただ、そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。

そもそもまず、なぜ悩むところがあったのか。

Firebaseのデータベースのデメリット

一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。

RDBのデメリット

とりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。サーバー内に入れると管理やスペックの調整などが気になるし、別途RDSやCloud SQLを使うと当然お金がかかる。

Heroku等のPostgresやJawsを使う手もあるが、あまりにも容量が少なすぎる。

Firebaseへの期待が高まりすぎる

RDBはメリットが高いが、やはりサーバーが不要というFirebaseのデータベースのメリットも同様に非常に高い。そのため、いつかバージョンアップした際にクエリが強くなるのではないか、もっとデータが取りやすくなるのではないか、みたいな期待が高まりすぎてしまった。

多分Datastoreを流用していると思うので、あまり期待しすぎても仕方なく、ひとまず現在は現状のままどうやって使っていくかを考える必要がある。Firebaseのデータベースを使うとなると、それでうまく作り方を考える必要が出てくる。（これはこれで面白いのだが）

どちらかに限定する必要はない

そこで気づいたのが、そもそも元々RDBを使っているアプリケーションであっても、Firebaseのデータベースを併用して使えばもっと便利になるのでは、ということ。

例えばこのCrieitの例だが、先日リアルタイムで下書きをライブ公開できる機能を作成した。

編集中の内容をライブ公開できるリアルタイム投稿機能を実装しました

このサイトはGoogle Compute Engineの永久無料枠で使えるf1-microというインスタンスで動いているのだが、とにかくメモリの使用量も小さく貧弱。Laravelは一応Pusher等と連携してWebSocketを使える機能があるのでLaravel自体でもライブ公開機能は実現可能なのだが、結局状態変化があった時にデータを取得などしようとするとLaravel自体にアクセスが行ってしまう。あまりに頻度が多いと、現在のサーバーのスペックでは厳しくなる可能性がある。

その時に思い出したのがFirebaseのRealtime Databse。これは同時接続数などの制限があるものの、書き込み、読み込み等の回数には特に制限がない。つまり、制限内でライブ公開する機能を付けるのであれば、サーバーの負荷ゼロでライブ公開機能が実現できてしまう。

実際に下書き入力中の内容は特にサーバーに保存する必要がないので、入力した内容はそのままRealtime Databaseに保存し、閲覧者側はそれを受け取るだけになっており、完全にサーバー負荷も費用的な負荷もなくライブ公開の機能が作れてしまった。無料で運営している個人開発サービスとしてはこのやり方はとても相性が良い。流行りすぎて人が増えるとそうはいかなくなるが、とりあえず今の段階では全く心配はない。むしろ遊び道具が一つ増えて楽しみが増えた。

逆で、Firebaseだけで運用しているサービスにRDBの利用を追加する、ということも考えられる。RDSやCloud SQLでは費用が増えてしまうが、とりあえずHerokuのPostgres等でも良いかもしれない。Firestore側が苦手とする集計や柔軟なページングなどを行いたいデータだけ、併用して保存することで、Cloud Functions経由で簡単に集計データなどが取れたりするのではないかと思う。

まとめ

とにかく柔軟に考えて、併用することでパフォーマンス的にも費用的にもベストな形になるような状態を目指していくと面白い。

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

2018-10-19T20:52:47+09:00

FirebaseのAuthenticationはGoogleログインやTwitterログインが簡単にできる便利なものですが、その中には匿名認証というものもあります。これが一体何のためにあるのか、セキュリティの観点から見てみます。今回はブラウザ上で動くWebアプリケーションの話です。

そもそも匿名認証とは？

匿名認証というのは、ユーザーが何も操作などをしなくても、内部で勝手にログインする機能です。

何のためにあるのか？

基本的には公式の説明にいきなり書かれています。

JavaScript を使用して Firebase 匿名認証を行う | Firebase

アプリに登録していないユーザーが、セキュリティルールで保護されているデータを使用できるようになります。

セキュリティとは？

Firebaseは便利ですが、怖いところがあります。Webアプリケーションの場合、JavaScriptを使うためFirebaseアプリケーションを初期化するための設定情報が丸見えになってしまいます。そのため、何のセキュリティも導入していないとその設定情報を使って誰でも勝手にそのアプリケーションの情報を読み書きできてしまいます。

それを制限する方法として、ForestoreやStorageにはセキュリティルールがあります。例えば以下のようなことが設定できます。

あるデータは誰でも閲覧できる
あるデータはログインしたユーザーしか書き込みできない

等。

セキュリティルールを設定しないとどうなるのか？

前述の通り設定情報が丸見えですので、それをコピーして誰かが自分のプログラムに組み込めば、他人のFirebaseのアカウントで自由にデータなどを扱えるようになってしまいます。

見られてはいけないデータが見られてしまいますし、そもそも利用量によって金額も増えてしまう恐れがありとても危険です。

匿名認証を使ったセキュリティ設定の一例

セキュリティ上問題ないと思われる、匿名認証を使ったシンプルな例をあげてみます。（一部誤りと追記修正を含んでいます）

全てのデータの読み書きを認証済みの場合のみ許可する

認証していない場合はあらゆるデータの読み書きを不可能にします。

匿名認証で誰もが必ず認証している状態にする

これで、ログイン機能がなかったり、手動でログインしたりしなくても全てのユーザーが読み書きできるようになります。

ログイン可能なホスト名を本番環境のみにする

Firebase ConsoleのAuthenticationの設定でログインできるホスト名を設定することができます。ここで本番のホスト名だけを認証可能にします。こうすることで、Firebaseの設定情報を使われてもデータにアクセスすることなどは不可能となります。

localhost等も当然消しておきましょう。開発時には別途開発用のFirebaseアプリケーションを用意し、そちらの設定を使ってください。ビルド時にはcross-envを使うと良いと思います。（誤りがあるので追記をご覧ください）

追記）
このホスト設定はリダイレクト用のため、匿名認証には利用できないようです。今のところ簡単に制限する方法はなさそうです。適切なセキュリティルールを設定してください。ルールの制限がないデータは今のところ他者に自由遊ばれる事ができてしまうのかもしれません…。良い情報があればぜひ提供をお願いします。

APIキーを制限する

Firebaseのコンソールでなく、GCPコンソールの方で制限が必要そうです。詳しくは下記に書きました。

GoogleからAPIキーが公開されているよとアラートが来た

まとめ

このように、匿名認証を入れることで本番でしかデータを扱うことができなくなり、セキュリティのベース部分の強化を行うことができます。（追記：前述の理由から、リダイレクトがないので本番以外でも扱うことはできるため、正しいセキュリティルール設定が必要です）

とにかく、設定情報が丸見えというのは非常に恐ろしい話です。当記事の話も鵜呑みにせず、しっかりと色々なパターンを考えセキュリティを強化しておきましょう。（むしろ間違っている話があればご指摘をお願いします）

Firebaseと連携するあらゆる処理をfunctionsに実装して設定情報は公開しないようにする、くらいの強固さで考えるくらいでも良いかもしれません。（認証の連携ができないので厳しいかもしれませんが）

Firestoreの参照型によるリレーションを試す

2018-08-06T21:59:54+09:00

FirebaseのFirestoreはNoSQLのため、コレクションの下にサブコレクションを登録するような形でデータをネストして登録していくことができます。ただ、これではRDBでやっているようなリレーションが実装できず、データが色々なところに分散してしまうため、各データを連携させる必要がある場合には非常に使いづらいです。一応リレーションもできるっぽいので、ちょっと試してみました。

※2018/8月現在、Firestoreがβバージョンのタイミングの記事となります。環境はJavaScriptです。

ちなみに、もうちょっと詳しく考察されている記事があります。

Cloud FirestoreのSubCollectionとQueryっていつ使うの問題

多分これのリレーションシップ参照型というところの話です。上記の記事ではManyToMany, hasManyあたりの話をしていると思いますが、今回試したのはbelongsToの話になります。

参照型

Firestoreに格納するデータには色々型があります。

https://firebase.google.com/docs/firestore/manage-data/data-types?hl=ja

この中を見ると「参照」という型があります。が、概念的なものが書かれているだけで、他のページを探してみても説明が見つかりません。（ただ見つけられていないだけか、βだからかは分かりません）

そのためとりあえずこれを使って1:1のリレーションができるか試してみました。

そもそも参照型と何か

データを追加するところのマニュアルを見てみると、addした後にdocRefという値が取得できています。もしかするとこれかな？　と思い、別のデータを保存する際にこのdocRefをそのまま代入して保存してみました。

      // userのdocRefをそのまま入れる 
      this.post.user = this.$store.state.user;
      db
        .collection("posts")
        .add(this.post)
        .then(docRef => {
          this.posts = getPosts();
        })
        .catch(error => console.log(error));

Firebaseのconsoleで見てみるとちゃんと入っていました。

body: "aaaa"
user: /users/scQa34jZbdF2mpuVcMMV

という感じで、参照型の保存自体はこんな感じでできるようです。

リレーションデータの取得

~~取得までは試していません。~~

ざっと１ファイルで適当に試してみました。適当なので実際に組み込む時は並列処理したりもっと良い書き方ができると思います。

const firebase = require("firebase");

const config = {
};
firebase.initializeApp(config);
const db = firebase.firestore();

async function execute() {
  // ユーザーデータを登録
  const userData = {
    name: "name" + (new Date()).getTime(),
  };
  const userRef = await db.collection("users").add(userData);

  // ユーザーデータを紐づけて投稿を登録
  const postData = {
    name: "post" + (new Date()).getTime(),
    user: userRef
  };
  const postRef = await db.collection("posts").add(postData);

  // 登録したデータを全部取得
  const querySnapshot = await db.collection("posts").get();
  const posts = [];
  querySnapshot.forEach(doc => {
    posts.push(doc.data());
  });

  for (let i = 0; i < posts.length; i++) {
    // リレーションデータを取得
    const post = posts[i];
    const userQuerySnapshot = await post.user.get();
    post.userData = userQuerySnapshot.data();
  }

  return posts;
}

execute().then(posts => {
  console.log(posts);
  process.exit(0);
});

とりあえず試しに動かしたサンプルも置いておきます。

Firestore Reference data type sample

GAE+NuxtのSSRでFirestoreを使う

2018-08-03T20:50:24+09:00

App Engineの標準環境でNuxtを使って無料SSR を先日やってみたので、今度はFirebaseのCloud Firestoreでデータの保存を試してみました。

ちなみにGAEのスタンダード環境ではNode8が動くため、ローカルでも全てNode8で動かす必要があります。

※また後日記事を書きますが、通常セキュリティルールが入っているため、実際にはcloud functions経由でfirebase-adminを利用してデータを取ってくる必要があります。

Firebaseの初期設定

plugins/firebase.jsに下記のように設定を保存します。

import * as firebase from "firebase";  
require("firebase/firestore");  

if (!firebase.apps.length) {  
  const config = {  
    apiKey: "your firebase api key",  
    authDomain: "your firebase auth domain",  
    databaseURL: "your firebase database url",  
    projectId: "your google cloud platform project id",  
    storageBucket: "your google cloud platform storage bucket",  
    messagingSenderId: "your firebase messaging sender id"  
  };  
  firebase.initializeApp(config);  
}  

firebase.firestore(); // もしかしたら要らないかも

そしてnuxt.config.jsで上記を読み込むようにしておきます。

  plugins: ["~/plugins/firebase.js"],

これでFirebaseのライブラリがNuxt上で利用できるようになります。

Firestoreへのデータ追加＆取得

元々あるindex.vueを下記のように修正し、データの一覧を追加してボタンを押すとデータを登録できるようにした最小のサンプルを作ってみました。（関係ないところは削っています）

テンプレート

テンプレートは単にデータを表示しているだけで特筆するところは無いです。

スクリプト

初期化

import db from "../lib/db";

DBを簡単に使える様にインポートしてすぐ使えるようにしています。これは別に必ず作らなければならないわけではありません。中身は単にdbを初期化して取ってきているだけです。

import * as firebase from "firebase";  
export default firebase.firestore();

データをFirestoreから取得してくる

ページを読み込むと、まずFirestoreからデータを取ってきて一覧します。

async function getTexts() {  
  return new Promise(callback => {  
    let texts = [];  
    db  
      .collection("texts")  
      .get()  
      .then(query => {  
        query.forEach(doc => {  
          texts.push(doc.data());  
        });  
        callback(texts);  
      });  
  });  
}  

export default {  
  data() {  
    return {  
      texts: [],  
      textInput: ""  
    };  
  },  
  async asyncData({ params }) {  
    return { texts: await getTexts() };  
  }  
}

データの初期化にmountedを使うことは多いと思いますが、これはサーバーサイドレンダリングでは動作しないため、代わりにasyncDataやfetchを使う必要があります。asyncDataは下記URLに使い方が載っていますが、async/awaitを使ったり、Promiseやcallback形式など自由に選べるようです。

非同期なデータ - Nuxt.js

あとこの中ではthisが使えないため、仕方なく適当にクラスの外にfunctionを定義してそれを呼び出しています。

あ、あとasyncDataはコンポーネントでは使えないため、今回はページ上で実行しています。実際の開発の際もコンポーネントで値を使いたい場合はプロパティで渡すか、storeを使うかになると思います。

データをFirestoreに追加する

あとは追加ボタンをクリックした時の処理を追加します。

  methods: {  
    add() {  
      db  
        .collection("texts")  
        .add({  
          body: this.textInput  
        })  
        .then(docRef => {  
          this.textInput = "";  
          return getTexts();  
        })  
        .then(texts => (this.texts = texts));  
    }  
  }

追加してとりあえず先程の一覧取得処理を実行しているだけです。

これでFirestoreにデータが保存され、画面上にも表示されます。Firebase Consoleのデータ一覧でも確認できます。

サーバーサイドレンダリングされているか確認

Google App Engineで動作させればサーバーサイドレンダリングされますので、一度ページをリロードして確認すればソース上に登録した文字列が存在するのが確認できると思います。（間違ってmountedで処理しているとSSRされません）

FIrebaseだとデプロイもあっというまでサーバー側の処理とか何も気にしないでいいので楽ですね！

あとはFirestoreにはリアルタイムアップデートの機能もありますので、一覧取得とかは頻繁に更新されるのであればそっちでやってみるのも良いかもしれません。

「Firestore」の記事 - Crieit

自分の理想の教室を、友達とリアルタイムで一緒に作れるウェブサービス「みんなのきょうしつ」をリリースしました。

Nuxt+Firebase Cloud Messaging(FCM)でWebプッシュ通知を送る

Firestoreの簡易管理ツールをNuxt.jsでつくってみた

Nuxt.js(SPA)+FirebaseのWebアプリで初マイグレーションをしてけど、いろいろ失敗した話。。

Firebaseで作ったWebサービスを3ヶ月運用してみて、ハマったこと・知っておきたかったこと

ドキュメントフィールドの削除はFieldValue.delete()

更新するときは、updateとset({merge: true})がある

Nuxt.js＋Firebase＋GAEで作った個人サービスが半月で2万PV超えたので実績値を全て公開する

複数のプロジェクトのfirebase-adminを起動して、開発用に本番データの一部を移行する

Firestoreのデータを分析するための3つの方法とその注意点

2. node-firestore-import-exportでローカルにエクスポート

2. node-firestore-import-exportでローカルにエクスポート

3. 別プロジェクトにデータを移行して、別プロジェクト上で確認(この記事)

Firestoreのデータをgcloudを使ってバックアップ＆別のプロジェクトへインポートしてみる

ローカルPCでfirebase-adminを使って一括削除/一括更新する

積読を解消をうながすWebサービス『積読ハウマッチ』をリリースしました!!!

Nuxt.js+Firestoreの場合に安全にSSRする方法

RDBとFirebaseのDB両方使ったっていいじゃない

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

ドキュメントフィールドの削除は`FieldValue.delete()`

更新するときは、`update`と`set({merge: true})`がある