JavaScript
vue.js
Firebase
nuxt.js

firestoreでlikeやfollowする際のデータ構成 / firebaseとNuxtでwebサービスつくったのでそのfirebaseまわり

ogimg_1.png
趣味制作で、これ最高なんすよ〜といったランキングを作れるサービス、COUCH(カウチ)をリリースしました。Nuxtとfirebaseを一通り使用しています。
先週Nuxt系の記事を書いたので、

Nuxt.js Advent Calendar 2018 5日目
NuxtのOGP対応について / firebaseとNuxtでwebサービスつくったのでそのNuxtまわり

今回はfirebase周りの話になります。

参考文献

vue, nuxt, firebaseの公式docが手厚く、流行ってるのでみなさん良い記事書くしで、自分が書くことないんじゃないかと悩みます。
まあ、とりあえずは参考&勉強になった記事から。

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/likeArticleLOGIN_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で良くない?と思ってしまう。月額かかりますし。
  • 一通り経験できたので、新サービスも短時間で作れるんじゃないかとわくわく