趣味制作で、これ最高なんすよ〜といったランキングを作れるサービス、COUCH(カウチ)をリリースしました。Nuxtとfirebaseを一通り使用しています。
先週Nuxt系の記事を書いたので、
Nuxt.js Advent Calendar 2018 5日目
NuxtのOGP対応について / firebaseとNuxtでwebサービスつくったのでそのNuxtまわり
今回はfirebase周りの話になります。
参考文献
vue, nuxt, firebaseの公式docが手厚く、流行ってるのでみなさん良い記事書くしで、自分が書くことないんじゃないかと悩みます。
まあ、とりあえずは参考&勉強になった記事から。
- Nuxt.jsとFirebaseでSPA×SSR×PWA×サーバーレスを実現する (新記事ありますが、構成変わったので旧記事のほうで)
-
分散カウンタ | Firebase
- 割り当てと制限 | Firebase
- 上記割り当てにある、書き込みとトランザクション/ドキュメントへの最大書き込み速度が 1 秒あたり 1と非常に少ないので、突発的な考慮が必要な項目は検討。
- Cloud Functions による Cloud Firestore の拡張
firestoreのlike, follow処理フロー
ちょうどfirebaseとNuxtの絡む内容があったので解説します。
個別記事、articles/<ARTICLE_ID>にloginUserがlikeしたとします。
sub collectionならまだしも、article doc自体はauthorしか編集出来ないようにしなければ、第三者の意図的な改変が可能になってしまいます。困る。なので、
articles/<ARTICLE_ID>/liker/<SHARD_NUM>/: LOGIN_USERがdocに<LOGINUSER_ID>を追加。
articles/<ARTICLE_ID>: functionsが↑の変更を検知。そのタイミングで、ここのlike総数を更新。
users/<USER_ID>/action/likeArticle：LOGIN_USERがdocに<ARTICEL_ID>を追加。
users/<USER_ID>：LOGIN_USERがarticleのlike総数を更新。
のような処理にすれば、like済みarticleはfront判断できるようになります。具体的には、自身のusers/<USER_ID>/action/likeArticleをlogin時からリアルタイムで更新取得しておけば、article表示毎に、このlikeArticleのidと一致するか確認できてfront処理だけでlike済みかの表示切り替えは可能になります。
限度はありますが、3000likeくらいまでは十分そうなのではないかと。
今回likeの場合で解説しましたが、followでも同じロジックでいけます。
ちなみに分散カウンタ、shared numのロジックは↓みたいな共有method作って使い回しました。楽。
function docShardCountsWrite (targetsRef, refId, docColName, shardsNum, afterCount, updateAt) {
const ref = targetsRef.doc(refId)
return ref.get().then(function (doc) {
if (!doc.exists) return
let likes = doc.data()[docColName]
let shardCounts = mergeObj(likes, 'shardCounts', shardsNum, afterCount)
let allCount = 0
Object.keys(shardCounts).forEach(key => {
allCount += parseInt(shardCounts[key])
})
let setItem = {}
setItem[docColName] = {
count: allCount,
shards_num: makeShardsNum(allCount),
shardCounts: shardCounts,
update_at: updateAt
}
ref.set(setItem, { merge: true })
})
}
おまけ
よかった開発サイクル
目標は毎日githubに草。
初日
- Nuxt setupとfirebase組込み
- firebase Hostingで一般公開までする
毎日
- 通勤中にスマホで表示確認。issueにメモる。
- 22:00過ぎくらいから簡単な改修スタート。スマホview改修から。
- 寝るまでに一度は本番deploy。designはpc viewメインでいい。
- 余力あっても当日新規開発した項目のスマホviewは完璧に仕上げない。
簡単なスマホview改修を翌日の初手にできるようにすると、PC立ち上げるハードル下がるのでよかったです。気持ち悪いので、帰ってすぐ直したくなる。
開発前の自分に言いたいこと
- rulesを早めに書こう。すごい簡単。updateのauthor権限確認など律儀にfrontでやってるけど消すことに。時間もったいない。
- firebase functionsのnode8系、早めに公式対応来るのでES6コンパイル環境すぐ消すことになる。タイミング悪かった。
firebase雑感
- 今回はDBをfirestore一本にしましたが、noSQLはRDBとは別物です。構成から取得から。良い悪いでなく、向き不向き。リアルタイム取得するようなchatデータなら本番まで生き残ります。強みを持ったまま。それ以外はプロトタイピング作成としてなら早くてありかも〜な感覚。課金まわりのセキュアなデータは導入したくない。
- functionsのfirestore監視トリガー便利
- rule最強
- firestoreに別サービスの全文検索いれるならRDBで良くない？と思ってしまう。月額かかりますし。
- 一通り経験できたので、新サービスも短時間で作れるんじゃないかとわくわく