「Firebase」の記事 - Crieit

【個人開発】作るのも、答えるのも簡単なWebアンケート「ankeyto」を作りました！

2022-08-31T09:35:31+09:00

2つ目の個人開発サービス公開

アプリケーションのモダン化を勉強しようと個人開発を始めて、以下の記事のように公開していました。もう振り返ると1年経つんですね…　こういった個人開発活動を続けることにより、少しずつ知識も身についてきて、開発スピードも上がってきていました。

Github Issuesをキレイに外部公開するサービス「2go」作ってみた
- https://qiita.com/nice2have/items/28449ae4ef45fef2c671
海外進出を目指して、ProductHuntへ個人開発サービスを投稿するまでにやったこと&やった結果を全面的にシェアする
- https://qiita.com/nice2have/items/f59a27c266efb9b8821c

実際には公開していないのですが、atodyという「Twitterでいいねしたツイートに含まれるリンク・画像だけを自動でまとめてブックマーク化できるサービス」を開発したのですが、いまいちサービスの完成度に納得がいっていなく、開発したサービスとしては3つとなったのですが、公開したサービスは２つとなります。

簡単Webアンケート

今回は会社の一定の範囲で簡単にアンケートを取りたいときに、Google FormｓやMicrosoft Formsを作るのは手間だな、もっとライトな感じで反応を知りたいなと思ったのがきっかけです。

また、アンケートの回答を得るまでのハードルが結構高いと思ったんです。アンケートURLにアクセスして、回答を入力して、、、となると、答えてくれる人が少なくなってしまって、アンケートの価値が薄まってしまうような気がしたんですよね。

機能を最小限に絞ったアンケートをリリースしよう

これらの課題を解決しようと、ankeytoというアンケート機能を最小限に絞ったサービスを開発しようということに至りました。ankeytoはアンケートのモジりで「アンキート」と名付けることにしました。ちなみに、先程のatodyも「あとで」のモジりで「アトディ」と名付けています。

https://ankeyto.com

開発する前の大まかなコンセプトは、A3ノートにまとめる用にしているのですが、汚い字で申し訳ないですが、公開してみます。

サービスのコンセプトは以下の２つと設定しました。
+ 最大３つまでの選択肢
+ 選択肢ごとのURLにアクセスすればもう回答済みになる

そのため、選択肢を表示して回答ができるページをSNSでシェアするのではなく、アクセスしたら回答できるURLをSNSでシェアするだけで良くなるのです。例えば、「これが良いと思ったら、このURLにアクセスして！」と言えば良くなり、アンケート回答のステップとハードルを減らすことができるのです。つまり、個人個人で対象への「いいね」を調査・獲得できるイメージです。

画面イメージ

こちらのようにアンケート回答がリアルタイムにグラフやUIに反映されるので、回答が多いと変化を楽しめるかもしれません。例えば、プレゼン最中の意見を軽く聞きたいときや、勉強会のフィードバックを簡単に得たいときなどに利用できるかもしれません。

アンケートを作るときの画面も極力シンプルにしています。こちらもログインが必要だと手間が増えてしまったり、入力項目数が多いと途中で離脱してしまう可能性が高くなってしまうので、最小限にすることを意識しています。

利用技術

個人開発者としてはまだまだペーペーなので、利用技術も運用負荷が最小限になることを意識しています。
- Firebase(Firestore/Functions/Hosting)
- Vue.js
- Tailwindcss
- Slack

サービス自体がとてもシンプルなので、HostingでWebページを表示し、質問作成や回答をFunctionsで処理し、結果をFirestoreでリアルタイムに反映しているだけです。一応、モチベーション維持のために、質問が作成されたり、回答されたりしたら、FuncitonsからSlackに通知されるようにしています。

将来に向けて

最後に、将来は以下のロードマップを考えています。
- URLにアクセスするよりもさらにハードルを下げるために、URLをQRコード化できるように。
- Cookie等を利用した重複回答者の防止機能
- 質問IDをランダムでなく、わかりやすいIDを提供できる機能
- API機能（UIだけでなく、いいねAPIを提供）
- 英語対応

最後に。

まさにこのankeytoを利用して、このWebサービスってどうですか？とアンケートを取って終われればと思います。以下が質問ページから、SNS共有用にコピーできる文章になります。「いい！」か「まあまあ」のURLにアクセスすれば回答が完了しますので、ぜひよろしくお願いします！

Q. このWebサービスってどうですか？
https://ankeyto.com/q/BbDJA3P11

いい！ : https://ankeyto.com/BbDJA3P11/1
まあまあ : https://ankeyto.com/BbDJA3P11/2

また、個人開発の進捗などを垂れ流すTwitterもやっていますので、こちらもよろしければフォローお願いします。
https://twitter.com/jnakajima1982

Windowsのnvmのnodeでfirebase-toolsを入れようとしたらUnexpected token '.' エラー

2022-07-17T11:29:34+09:00

npm install -g firebase-tools を実行してインストールしようとしたら下記のようなエラーが出た。

npm ERR! Unexpected token '.'

調べてみたらどうもWindowsのnvmのバージョン1.1.7以下を使っている場合に発生してしまうらしい。

ということで

nvm最新をインストール
Nodeの該当バージョンをアンインストール
Nodeの該当バージョンを再度インストール

で解決するとのこと。nvmだけでなくNodeも入れ直さないといけないっぽい。

参考）
https://github.com/firebase/firebase-tools/issues/4134

数日で有料サービスをリリースしてみた話

2021-11-17T09:36:55+09:00

有料サービスを２，３日位で作ってリリースしてみました。多分計10時間ほど？　急にぱっと思いついて次の日の夜くらいにはだいたい完成していました。作ったのは下記のHand Refactorerというプログラムのコードを手動的にリファクタリングしてくれるサービスです。

130円でプログラムのコードを手動的にリファクタリングしてくれるサービスをリリースしました。プログラミングを始めたばかりの方にはもしかしたら役立つ場合もあるかもです。よろしければお試しください！！https://t.co/bHlNXJFbTh pic.twitter.com/VhPI80a6Cl
— だら@Flutterもやってる (@dala00) November 14, 2021

ちなみにこれ自体は単に自動的じゃなくて手動かよというツッコミがほしいだけのために作ったネタクソアプリです。

色々やるべきことを削ったりなどで考えたりしたので書いておきます。

サービスの流れ

そもそもサービスの流れですが、まずユーザーがリファクタリングしてほしいコードを入力して登録します。

それを僕が人力でリファクタリングし、回答として登録するとユーザーがそれを確認できる、という形です。

課金関連の開発を極限まで削る

課金となると、結構色々考えなければなりません。ユーザー登録し、そのユーザーに対して課金ログを保存し、購入履歴などを用意する必要があります。ただそこまでするとどうしても工数がかかってしまいます。そのため下記のようにして開発事項を削りました。

オーソリを使う

オーソリというのは、仮売上です。即課金確定するのではなく、注文が確定した時にキャプチャという処理を行って決済を確定させる方法です。ユーザーが注文してきた時に仮売上とし、僕が処理を行って納品でき、ユーザーがそれを意図的に閲覧した場合に納品確定としキャプチャを行うようにしました。

この方法には色々メリットがありました。

ユーザーの心理的不安を取り除ける

個人サービスですので、そこに課金するのにはちょっと不安があります。ただ、ちゃんと納品が行われないと課金が確定しないということが事前にわかっていればその不安をある程度取り除くことができます。

確定する場合には、ユーザーに回答画面のURLが貼られたメールが送られます。ここでも実際に見て課金を確定するかどうかをユーザーが意図的に選ぶ事ができます。興味がなければ見ずに終わらせればいいですし、お金を払ってでも見たいと思っていれば閲覧して確定できます。

運営側の不安も取り除ける

個人サービスで課金機能を提供するのは、運営者としてもなかなか気持ち的に不安になることが多いです。うまくサービスを提供できなかったらどうしよう、大きなミスに気づかず迷惑をかけてしまったらどうしよう、など。

しかしオーソリを利用してユーザーがお金を払って結果を見たいと確信して行動する時に初めて課金が行われるようにすれば、なかなか間違えたり問題が起こる可能性は低くなります。そうなると運営側としても問題が発生しにくく安心です。

また、最悪僕が怠けたりなにか急なトラブルで全然手を付けられず放置したとしても一切課金されることはありません。また、そんなにリファクタリングすることがないコードであれば確定しないことでキャンセル扱いにすることもできます。

このようにしてお互いの不安をなるべく少なくすることでユーザーは購入を、運営はリリースをしやすい気持ちにできるようにしました。これができなければ色々と複雑なテストをしたり入念にいろいろな機能をつくったりしてなかなかリリースはできなかったでしょう。

チェックアウトを使わない

Stripeにはチェックアウトというプログラムを書かなくても商品を売れる機能があります。すごく簡単なのですが今回はそれは使いませんでした。というのも売上の結果を知るためにWebhookでチェックする必要があり、ちょっとそれが面倒でした。プログラムで決済してしまえば登録時に一緒にやってしまえばすべてが終わるためそちらの方が処理的にもわかりやすくテストもしやすかったためです。

メールアドレスを使う

メールアドレスを使うことでログイン機能を削りました。ユーザー登録をすると、やはり離脱率は上がります。ちょっと投稿して利用するだけのサービスでユーザー登録は面倒くさいです。

また、ログイン機能を作るとそれはそれで結構面倒です。Next.js と Firebase を使っているのですが、それで認証を入れるとFirestoreのセキュリティルールも設定しなければなりませんし、その状態だとNext.jsのサーバーサイドレンダリング時にエラーが発生することもあり、結構確認事項が増えます。ログイン機能を作らずメールアドレスのみの照合とすることでそれら全ての開発を削りました。

メールアドレスだけでは勝手に決済されて危険なのでは？　と思われるかもですが、クレジットカード自体は操作している人自身のものを入れなければならないためなりすましは難しいですし、できたとしても結局オーソリまでしか進めないため、利用者が最後まで進まないとお金は一切動きません。

またこれにより結果のURLはメールで本人しか知ることができないため漏洩の心配などもありません。

最初はユーザーもメールアドレス登録するのはいやかな…とも思ったのですが、そもそも大量の依頼がくるとそれはそれで僕のスケジュールがパンクしてしまうのである意味抑制になっていいかなと思っています。

極限までハードルを下げる

このハードルというのはユーザー、運営者両方のことです。

まず費用は130円という自販機でジュースを買うのと同じ（？）ような料金にしました。また、説明分にはレジャー感覚で使ってほしいということ、意図した結果が帰ってくるとは限らないということを書いておき、運営者的にもちゃんとした結果をださなければ、という不安をなくし、利用者としてもさほど結果に期待しない状態を作っておきました。

ハイクオリティになったり、ハードルの認識の齟齬があると開発もそれに対処するためにちょっとやることや考えることが増えたりなど、すぐにリリースはできません。とにかくすぐに作るレベルのサービスに連動したクオリティの商品をそれに見合った低価格で提供することによってリリース時の負担を下げました。

管理機能を公開しない

リファクタリング結果の送信ですが、Firestoreのダッシュボードだけではできません。そのためそこは返答用の画面を作ってあげる必要がありました。

しかし前述の通り認証もありませんし、URLを作ってしまうと万が一アクセスされてしまった時に情報が漏洩してしまいます。

そのため管理画面は公開せず、別プロジェクトとして作り、ローカルのデバッグ実行だけでできるようにしました。絶対に他の人にアクセスされることもありませんので安全です。また、作っていたプログラムをコピーするところから始めたのでベース部分はまるまる流用でき、特に大変でもありませんでした。

Firebaseクライアントを使わず全部APIのみにする

前述の通り、セキュリティルールを設定するのが面倒だったためFirebaseのクライアントはアクセス解析にしか使っていません。セキュリティルールは全部のデータへのアクセス不許可にしています。

普通に単なるAPIとしてfirebase-adminを利用してサーバーサイドのDBのようにして作っています。なにもかんがえることもなく非常に楽です。勝手に変なデータにアクセスされてしまうこともありません。

また、Firestoreを使うことによってデプロイする場所を選ばなくてもよいようにもなっています。

Cloud Runにデプロイ

今回はCloud Runにデプロイしました。前述の通りDBはFirestoreなのでどこにでもデプロイできます。本来はVercelが一番楽なのですが、この無料プランは個人的な利用のみに限られますので、今回の場合は利用できません。ということでCloud Runを使いました。GitHubにpushしたのに連動して自動的にデプロイもできますし。Herokuでも良いと思いますが頻繁に利用されるサービスではありませんし、あまりアクセスして遅いのもあれかなと思いCloud Runにしました。

せっかくなのでDockerfileを使わないでデプロイできるBuildpackというものを試してみたかったというのがあったのですが、どうもビルド無しで実行されてしまうようでエラーになったので今回は諦めてDockerfileを使うことにしました。だいたいDockerfileならどっかーにあると思いますので。

今回は下記を使いました。
【Node.js/Next.js】Cloud Runで動作する軽量なDockerを構築してみた

これの真ん中のやつでだいたいデプロイに8分ほどかかります。それほどパフォーマンスが必要ではないので一番最初の簡易的なやつでも良かったのかもしれません。なんにしろVercelよりはやはりどうしても遅くなってしまいますね。

あと日本リージョンにしたのでちょっとネットワーク料金がかかります（アクセスがちょっと多ければ月何十円とか100円とか？）

CSSも使わない

今回はChakra UIを使いました。とにかくデフォルトのデザインパーツで、カスタマイズは全部Chakraコンポーネントのプロパティのみで、ぶわっと作りました。非常に楽です。

DIFFの表示

リファクタリングということで、DIFFを表示したほうがわかりやすいかなと思いました。

React Diff Viewerというのを使いました。
https://github.com/praneshr/react-diff-viewer

まとめ

最初に書いたとおりクソアプリですので、ものすごい依頼が増えない限りは特にアップデートする予定はありません（依頼がきたらちゃんと対応します。リファクタリングは結構好きなのでわりと楽しんでやっています）。

ただ数日で作れたので、これを機に低価格で同じように自分で提供できることを売るのも面白いかなとは思います。どうしても手がかかるので規模が大きくなるとスケールもしないし限界がありますので、あくまでも今回のようにジョーク交じりかつすごく負担の少ない作業だけになるとは思いますが。

逆に言うと、低価格でちょっとなにか提供できる、というひとはたくさんいると思いますので、みんながこういうサービスを各々作れたら面白いのにな、とも作ってる途中に思いました。例えば小説の手直し、絵の手直し、もしくはちょっとした絵を書いてあげたり、サービスの感想を伝えてあげたり、なにか写真をとってあげたり、ロゴをつくってあげたり。皆自分の得意なことを提供して少しでもお金になれば楽しいのでは、と思いました。

もちろんそういうモール的なサービスはいくつかあると思いますが、あくまでも自分の個人商店的な感じで運用するのも面白いと思います。

自分でみんながそういうことを提供できるサービスを作ればよいのでは、とも一瞬思ったのですが、やはり価格的に運営者に入るお金はかなり薄利になり、儲けを出すにはかなり大量に集客しないといけませんし個人だと逆に大変なことが多そうなので、無理かなと思いました。Skebのもっと安くて気軽バージョン的な感じかもです。

なので可能な方は是非同じ様なサービスを作ってなにか提供してみると面白いのではないかと思います。

QnQ開発日誌 Firebaseで管理者用画面はみんなどうしているのかな

2021-11-04T13:27:28+09:00

相変わらず発起人の友人を含む3人でQnQの開発を続けている。

Search | QnQ

友人が今細かな使い勝手のブラッシュアップをしてくれているので、僕はチーム制導入にあたって、管理者用のコマンドラインツールを作成している。本当は管理者用の画面を作ろうと思っていたんだけれど、セキュリティルールが面倒臭いことに気づいた。

面倒臭い

このWebサービスはFirebaseを使っている。Firebaseは何かと便利ではあるものの、メンテナンスを考えた時にちょいちょい引っかかる。前にも「一時メンテナンスとかどうやるんだろう」と思ったが、調べてみると「意図的にしばらく落とす」みたいなのはなさそうで、強引なリダイレクト処理を入れている人なんかが引っかかった。

今回は管理者用の画面いい加減必要だね、という話をしていて、それ用の画面を作ろうかなと思っていたんだが、そうするとけっこうセキュリティルールが面倒臭い、ということに気づいた。

多分、一部のユーザを「管理者」として、セキュリティルールで都度管理者用の穴を開ける、ということになるだろう。別にやってできないことはないが。

とはいえ、ただでさえうんざりするようなセキュリティルールの記述がさらにややこしくなるのか、とか、管理者特権持っちゃうと、デバッグを兼ねて触っているのに、エラーに気づけなくなりそうだな、とか、色々思うところがあって、うーん、どうしようかなぁと考えた末に、例によってコマンドラインの管理者ツールをシコシコ作ったのだった。

コマンドラインならばAdmin SDKで気にせず書けるし、node.jsじゃなくてPythonでも書ける。入出力を整えてやれば、パイプを使ってそれなりに複雑な操作もできるし。結局こうなるのか。

使い勝手の向上

後は友人が細かな使い勝手の向上に繋がるところをやってくれているようだ。たとえば通知欄で、スレッドAの#20番とあったとして、これを開くとスレッドAの#20番まで飛ぶんだけれど、これまでスレッドAを開いていると#20番に飛んでくれないという謎の状態になっていた。

致命的ではないという感じで放っていたんだけれど、やっぱり不便だった、ということでなおしてくれたんだが、なおってみるとだいぶありがたく思えた。

やはりUXはこういう泥臭い改善の積み重ねなんだなぁと思う次第。全体最適を見失った局所最適は問題だけれど、全体ばかり見て細部を疎かにするのもやはりよくない。

最近「サービスが終わるソシャゲ」をあえていじったりしてみたが、共通して「ゲームのシステム部分がまどろっこしい」というのがあった。同じ作業を嫌がらせのように繰り返させられる、みたいな。できないことはないけど、面倒、という感じ。

今のこのサービスもそういう状態だよなぁ、と反省する。僕は過去「そもそも方向性おかしい」問題に振り回され続けた苦い経験があって、全体最適の重要性については身に沁みているのだが、一方で局所最適の重要性を過小に評価しているのかもしれない。

全体最適と局所最適のバランスは難しく、きっと永遠の課題なのだろうけれど、自分なりの距離感を見つけていきたいものだ。

FirebaseとSSSAPIでプレスリリースを送ったサイトを記録できるWebサービスを作ってみた

2021-10-05T17:05:54+09:00

開発しているGoogleスプレッドシートのAPI化サービス「SSSAPI」をβ版リリースしたときに、
プレスリリースをいろんなメディアに送ってみてた。

せっかく調べてまとめたし、次も使う機会があるだろうと思ったので、
Nuxt/Firebase/SSSAPIの構成でWebサービス化してみた。

プレスリリースを受け付けてるサイトを調べるのは大変なので、
どこに送れるのかな〜と思った方は使ってみてもらえるとうれしいです(´ω｀)

作ったサービス

https://press-done.memory-lovers.com

送付するプレスリリースごとに、どのサイトへ送ったかの状態管理ができます。
それだけのシンプルなWebサービス。

システム構成

基本構成はこんな感じ。

フロントエンド: Nuxt+Buefy
認証: Firebase Authentication
ユーザデータ: Firestore
マスターデータ: SSSAPI

ユーザが更新しないマスターデータはSSSAPIを利用している感じ。

メディアサイトのデータをFirestoreに入れておく形もあるけど、
Firebaseコンソールで追加や編集するより、
スプレッドシートを更新するほうが楽なので、この形にしている。

スプレッドシートの中身はこんな感じ。

SSSAPIはこんなJSONを返してくれる。

[
  {
    "id": 1,
    "サイト名": "TechCrunch Japan",
    "サイトURL": "https://jp.techcrunch.com",
    "送付方法": "メール",
    "isActive": true
  },
  {
    "id": 2,
    "サイト名": "日経クロステック",
    "サイトURL": "https://xtech.nikkei.com",
    "送付方法": "メール",
    "isActive": true
  },
  {
    "id": 3,
    "サイト名": "ITmedia",
    "サイトURL": "https://www.itmedia.co.jp/",
    "送付方法": "メール",
    "isActive": true
  },
]

※「行数をIDとして追加」オプションを使ってるので、idが自動で付与されています。

このスプレッドシートは登録依頼のGoogleフォームと連動しているので、
追加依頼があったら内容を確認してisActiveをtrueにすれば反映されます。

こういった構成は割と多く、本の貸し出し管理と備品管理とかでも使える。
Webサービスからスプレッドシートを編集できないので、
管理者権限とか不要なので、その分フロント側も楽に作れた(´ω｀)

プレスリリースってどこに送れるのかな〜と思った方は、
ぜひ使ってみてもらえるとうれしいです(´ω｀)

https://press-done.memory-lovers.com

SSSAPIはβ版ユーザを募集しています!!

β期間中はプレミアムプランの内容を無料で使えるのでお得！
ぜひぜひ、この機会にお試しいただければ！

わからないところやこんなのあったらいいなぁ〜などあれば、
Twitterやお問い合わせなどからお気軽にご連絡ください〜

GoogleスプレッドシートのAPI化サービス
『SSSAPI』
Twitter: @sssapi_app

https://sssapi.app

開発の励みや記事を書くモチベにもなるので、
いいねやシェア、はてブなどしてもらえるとかなりよろこびます!!

QnQ開発日誌単体テストなしで大丈夫か？

2021-07-30T02:39:33+09:00

デプロイしたらサインインしていない状態でサイトが見られなくなった、QnQの開発日誌ですこんにちは。今は修正している。

Firebaseのセキュリティルールをミスっていたせいなんだが、Seleniumを使ったUIテストしかなく、匿名ユーザーの挙動がテストケースから漏れていたために気づかなかった。

単体テストがない

この程度のことは単体テストでやるのが良いのだろうと思うのだが、開発メンバーで真面目にフロントエンドをやってきた者がおらず、なかなかハードルが高い。まずVue.jsという時点で経験がないのに、そのうえFirebaseが絡むので、どうにも手を付けられていない。せめて、新しい知識がどちらか片方ならまだなんとかなったと思うのだが……。

UIテストだけ

そんなわけで、せめてこれくらいは……とSelenium IDEを使ってUIテストだけなんとか実行している、というのが現状である。

正直これがあるだけでも実は頑張った。さすがに何のテストもないのはまず過ぎる、と思って作ったのだが、大きな修正のたびに思いもよらないところでテストで引っかかってくれているので、実際役に立っている。

ランスルーテストを流すと普通に数分かかるが、まぁその間はコーヒーでも入れて飲めばいいのだ。

単体テスト入れたいというより

しかしまぁ、さすがにそろそろ単体テスト入れなあかんよなぁと思うのだが、それにしてもハードルが高い……。

というかコードがスパゲッティで非常に汚いし、そもそも抜本的にこのUIどうなの？と非常に思うところあるので、ぶっちゃけフルスクラッチで最初から書き直したほうがいいのかもしれない、とか思う。

ダイエットとバグ修正の話を一緒にできる、そうQnQならね

ちなみにこのバグ修正は、友人とWebサービス上でやりとりしていた。GitHubでもやりとりしたけど。俺の日記帳状態だったが、再び友人との交換日記状態に復帰している。やっぱり複数で使うと楽しい。

もくもく22 2021-07-28 | QnQ

で、上記のスレなのだが、このサービスの特徴が出ている。

上図のように、「ダイエットの話」と「バグ修正」の話を並行している。こういう体験は他ではないはずで、自分たちでは「面白いと思うんだけどなぁ」と言いつつ、閑古鳥が鳴いている僕らのサービスである。

なんか面白そうだなと思ったら、覗いてやってください。

週末の時間を使って「みんなのきょうしつ」をアップデートしました。

2020-06-07T19:47:07+09:00

promitsuです。

今週の土日の空いた時間を使って、先日リリースした「みんなのきょうしつ」というウェブサービスのアップデート作業を行いました。

http://class-room.fun/

このアプリは、リアルタイム同期な共同編集機能により、オンライン上の別々の場所やデバイスから、友達と一緒に好き勝手に教室（という名の座席表）を作成し、その画像をシェアできるサービスです。

開発の経緯などについては下記の記事を参照ください。

https://crieit.net/posts/620b85ee075fd93545b20ccfb92d3491

アップデート

先日のリリースは、複数人でリアルタイムに「教室」（座席表）を作成できるという目的のもとに、最低限の機能のみに絞った仕様になっていました。その後、友人などに使ってもらい、フィードバックをもらった内容について、以下のような機能追加や修正などを行いました。

※ 前提としてこのサービスはNuxtjs（Vuejs）とFirebaseを使って開発・運用されています。

主な内容

ステータスのタイプライター表示

黒板に表示される生徒のつぶやきをタイプライター風に１文字ずつ表示するようにしました。
普通に文字列を配列化して、一定間隔おきにv-modelの配列にpushする感じでJavascriptで実装しました。

教室ページのデザイン・レイアウト修正

VuejsもFirebase(firestore)もまともに使ったことがなかった３月ぐらいに一日間の突貫作業で作った時のままだったので、HTML/CSSの構造から、Vueコンポーネントの構成などもリファクタリングしました。

いいね機能

現状ユーザー認証がないので、SessionStorageに自分がいいねした教室の情報を保持し、多重いいねを防ぐようにしました。
実装にはvuex-persistedstateを使っています。
これ以外のデータの読み込みなどはvuexfireを使って、vuexのstoreとfirestoreをシームレスにつないでいるので、moduleとして分けてindex.jsから読み込む構成にしています。

```jsx
store/
  |
  +-- index.js
  |
  +-- like.js

```

store/index.js

import like from './like'
import localStorage from 'vuex-persistedstate'

...

export const plugins = [
  localStorage({
    key: 'like',
    paths: ['like'],
    storage: window.sessionStorage
  })
]

vuex-persistedstate
https://github.com/robinvdvleuten/vuex-persistedstate
vuex-persistedstate
https://github.com/posva/vuexfire

公開教室のトップページでのリスト表示

これがないと他にどんな教室があるかわからんし、アクセスもできないという指摘。ごもっともですね😓

座席削除

作成・編集ができるのに、削除できないとは何事か！？というご指摘。さーせん。

公開・非公開設定

トップページにリストが表示される様になったので、他の人にアクセスしてほしくない人は非公開設定にできるようにしました。秘密の言葉による簡易認証を入れようかとも思ったのですが、ユーザーから見た複雑度が増す気がしたので一旦ペンディングにしました。

教室背景変更機能

だだっ白い無味乾燥な背景が寂しかったので、教室の背景画像を変更できるようにしました。アップロード時の画像リサイズ・クロップなどはまだ実装できていないのでIssue積んどきました。

ドラッグ&ドロップ編集機能

vue-draggableを使って実装しました。（Vuejsは便利なコンポーネント・ライブラリが充実してるので、個人開発者にはとても嬉しい😭）
もちろん編集結果はリアルタイムに他のデバイスに反映されるようになっています。（挙動をもうちょっとかっこよくしたい😓）

動作ムービー

https://www.youtube.com/watch?v=2RCYmpFSae8

vue-draggable
https://github.com/SortableJS/Vue.Draggable

その他の修正（レイアウト変更、バグフィックス等）

背面黒板を廃止して、全面の黒板につぶやきを表示するようにしたり、その他微妙なデザイン・レイアウト調整、及びバグ修正を行いました。

まだまだバグも多いし、実装したい機能や修正したいUX、インタラクションなどもたくさんありますが、地道に少しずつ良いプロダクトにしていこうと思います。

ではまた。

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

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の動的生成あたりとか、記念写真機能あたりについて、あとで技術的なことを書こうかなと思っています。

それではまた。

好きな楽曲について語り合うウェブサービス「musico」を作ってみました。

2020-06-05T19:26:08+09:00

突然ですが、先々週に行われたweb1weekという1週間でウェブアプリを作って公開するオンラインハッカソンに参加しました。

（5/18～5/24）１週間でWebサービスを作るイベント - お題「Like」

と、言いたいところだったのですが、実は2日目以降、家庭内のインシデント対応やそれに起因する自身の体調不良で、全く開発を進めることができませんでした（汗）

昨日あたりから、体調含めて状況が落ち着いてきたので、遅ればせながら開発を進め、ガっと最低限の所まで作り込み、勢いでドメイン取って公開してみました。

以下、今回開発したウェブアプリについて。

お題は「Like」でしたので、好きな楽曲についてあーだこーだ語り合えるサービスを作ってみました。

「musico | find track you like and talk about it」（何故か英語ｗ）

フリーワードで楽曲を検索して、その楽曲にLikeやコメントをすることができます。

現時点での機能は以下、

未ログイン時

楽曲を検索、またはコメントがある楽曲リストを閲覧できる
楽曲のコメントページを閲覧できる
楽曲のプレビュー再生ができる（ファイルがあるもののみ）
Spotifyで楽曲を聞くことができる（別タブでウェブ版を表示）

ログイン時

上記に追加して、
- 楽曲にコメントできる
- 楽曲にLikeできる

動作ムービー

https://youtu.be/sDVK6O61_S0

各楽曲、コメントごとのページをSNSにシェアすることも出来ます。

https://musi-co.fun/tracks/6K53GM9W6Vle5KBwGFVnZM

開発時の様々や動機はなどは下記のハッカソンのボードに書きました。
https://crieit.net/boards/web1week-202005/musico

技術的なこと

技術スタック的にはFirebase+Vuejs（Nuxtjs）という、マネージドなサーバレス環境とコンポーネント思考なリアクティブフレームワークを組み合わせたJAMstackな流行りの構成です。

最初はホスティングにNetlifyを選択したのですが、SSR周りやFirestoreなど他に使ってるサービスとの兼ね合いも考えて、Firebase全乗っかりな構成にしました。

UIは最近良く使ってるBulmaのコンポーネントをほぼほぼそのまま使ってる感じです。

本業ではAWSがっちり使って、コンテナとかサーバレスとかマネージドサービスを組み合わせたサーバサイド寄りの開発が多いので、個人開発ではフロントエンド寄りの技術を選定しがちですね（汗）

あんまり凝ったことはしていないのですが、開発時に得た知見は今後すこしずつ書いていこうと思っています。

それではまた。

PS.

祝Crieit初投稿！！

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

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

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

使い方

構成は、@nuxtjs/pwaでPWA化している感じ。

コンソール側

Settingsでウェブプッシュ証明書を作成して、鍵ペアを取得する。

これを、PUBLIC_VAPID_KEYという環境変数に設定しておく。

クライアント側

firebaseの初期化

~/plugins/firebase.tsというファイルを用意し、firebaseを初期化

// ~/plugins/firebase.ts
import * as firebase from "firebase/app";
import "firebase/auth";
import "firebase/firestore";
import "firebase/messaging";


if (!firebase.apps.length) {
  // まずは、firebaseの初期化
  firebase.initializeApp({
    apiKey: process.env.API_KEY,
    authDomain: process.env.AUTH_DOMAIN,
    databaseURL: process.env.DATABASE_URL,
    projectId: process.env.PROJECT_ID,
    storageBucket: process.env.STORAGE_BUCKET,
    messagingSenderId: process.env.MESSAGING_SENDER_ID,
    appId: process.env.APP_ID,
    measurementId: process.env.MEASUREMENT_ID
  });

  // Push通知をサポートしているかをチェック
  // サポートしていないと、firebase.messaging()を呼んだときに例外が発生
  const isSupported = firebase.messaging.isSupported();

  // コンソールで発行した、ウェブプッシュ証明書の鍵ペアを取得
  const publicVapidKey = process.env.PUBLIC_VAPID_KEY;
  if (!!publicVapidKey && process.client && !!isSupported) {
    // FCMの初期化。鍵ペアを設定する
    const messaging = firebase.messaging();
    messaging.usePublicVapidKey(publicVapidKey);

    // @nuxtjs/pwaが生成するsw.jsと、
    // 後で作成するFCM受信処理用のsw-firebase-messaging.jsを統合するための設定
    navigator.serviceWorker
      .register("/sw.js")
      .then(registration => messaging.useServiceWorker(registration))
      .catch(err => console.error(err));
  }
}

export default firebase;

トークンの取得

Push通知を送る際の宛先として、トークンを指定しないといけないので取得。
トークンは端末ごとに取得する必要があるので、注意が必要。
※PCとスマホだとそれぞれトークンが違う

import firebase from "~/plugins/firebase";

// トークンの取得
public async getToken(user: User) {
  const isSupported = firebase.messaging.isSupported();
  if (!isSupported) return;
  const token = await firebase.messaging().getToken();

  // firestoreにトークンを保存しておく処理(中身は略)
  await saveToken(user, token);
}

Firestoreなどへユーザごとにトークンを保存しておく。

firebase.messaging().getToken();を呼んだ際に、
通知の設定が「確認」だと、許可を求めるダイアログが表示される。

これが許可されていないと、トークンも取得できない。

メッセージを受け取ったときの処理

メッセージを受信したときに受け取る関数は2つあり、

フォアグラウンド(画面を見ている時) ... onMessage
バックグラウンド(画面を見ていない時) ... setBackgroundMessageHandler

・【参考】JavaScript クライアントでメッセージを受信する | Firebase

今回はバックグラウンドのときに通知を送りたいので、
setBackgroundMessageHandlerを設定していく。

こんな感じ。

ドキュメントを見ると、『firebase-messaging-sw.jsというファイル名で作成』と書かれているけど、
その名前にすると、自動で読み込まれてしまう。。

開発用と本番用で切り替えたいときなどもあるので、@nuxtjs/pwaが生成するsw.jsと統合できるように、
sw-firebase-messaging.jsという名前でファイルを作成しておく。

ファイル名を変更したので、上で書いている「firebaseの初期化」の部分で、
messaging.useServiceWorker(registration)を呼んでいる形。

// ~/static/sw-firebase-messaging.js
importScripts("https://www.gstatic.com/firebasejs/7.14.2/firebase-app.js");
importScripts("https://www.gstatic.com/firebasejs/7.14.2/firebase-messaging.js");

// Firebaseの初期化
firebase.initializeApp({
  apiKey: "...",
  authDomain: "...",
  databaseURL: "...",
  projectId: "...",
  storageBucket: "...",
  messagingSenderId: "...",
  appId: "...",
  measurementId: "...",
});

// [START background_handler]
const isSupported = firebase.messaging.isSupported();
if (!!isSupported) {
  const messaging = firebase.messaging();
  // バックグラウンド時の処理
  messaging.setBackgroundMessageHandler(function(payload) {
  　// 受け取ったFCMの内容を取得
    const notificationTitle = payload.notification.title;
    const notificationOptions = {
      body: payload.notification.body,
      icon: payload.notification.icon,
    };

    // 通知を作成する
    return self.registration.showNotification(notificationTitle, notificationOptions);
  });
}
// [END background_handler]

nuxt.config.tsでPWA関連の設定をする

作成したsw-firebase-messaging.jsを取り込む設定と、
@nuxtjs/pwaが生成するmanifest.jsonに、gcm_sender_idを追加する設定を追加

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

const config: Configuration = {
  // 略
  modules: [
    "@nuxtjs/pwa",
  ],

  workbox: {
    // sw-firebase-messaging.jsをimportするように追加
    importScripts: [
      "sw-firebase-messaging.js"
    ]
  },

  pwa: {
    manifest: {
      // manifest.jsonにgcm_sender_idを追加
      gcm_sender_id: process.env.MESSAGING_SENDER_ID || ""
    }
  },
};

export default config;

これでクライアント側はOK！

サーバ側: メッセージを送信する

メッセージの送信は、firebase-adminでできる。
・アプリサーバーからの送信リクエストを作成する | Firebase

firestoreを利用しているので、Cloud Functionsのfirestoreトリガーを使い、
ドキュメントが追加されたら通知するようにしている例。

import * as functions from "firebase-functions";
import admin from "../common/firebaseAdmin"; // 初期化済みのfirebase-admin

export default functions
  .firestore.document("ドキュメントのパス")
  .onCreate(async (snap, context) => {
    // getTokenで保存しておいたトークンを取得(中身は略)
    const token = getToken();

    // 通知の送信
    const title = "通知するタイトル";
    const body = "通知する本文";
    const icon = "通知で表示するアイコン画像のURL"
    const link = "通知をタップしたときに開くURL"
    await admin.messaging().send({
        // 送信先の端末のトークン
        token: token,
        // 通知する内容
        notification: {
          title: title,
          body: body
        },
        // Web Push向けの通知内容
        webpush: {
          notification: {
            icon: icon
          },
          fcmOptions: {
            link: link
          }
        }
    });
  });

送信はこれだけ！

ほかの小ネタ

トークンを削除する

firebase.messaging().deleteToken();でトークンを無効化できる。

// トークンの削除
public async deleteToken(user: User) {
  const isSupported = firebase.messaging.isSupported();
  if (isSupported) {
    const token = await firebase.messaging().getToken();
    await firebase.messaging().deleteToken(token);
  }
}

フォアグラウンドで通知を受け取ったときになにかする

onMessageを使うと、通知を受け取ったときに呼び出してくれる。

firebase.messaging().onMessage(async (payload) => {
  // 受け取ったときの処理
});

トークンが変更されたときになにかする

onTokenRefreshを使うと、トークンが更新されたときに呼び出してくれる。
新しいトークンは再度getToken()を呼ばないといけない。

firebase.messaging().onTokenRefresh(async () => {
  // トークンが更新されたときの処理
});

通知の許可状態を確認する

通知の状態は、Notification.permissionで確認できるらしい。
・Notification.permission - Web API | MDN

if (Notification.permission === "default") {
  // 確認(デフォルト)
} else if (Notification.permission === "granted") {
  // 許可
} else if (Notification.permission === "denied") {
  // 拒否
}

以上!!

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

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

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

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

参考にしたサイトさま

iPhoneだけでWeb アプリの動作がおかしいときのデバック環境

2020-02-24T15:30:09+09:00

先日React + Firebaseで簡単なWebアプリを開発していたのだが、なぜかiPhoneのみでバグがでてしまうという苦しい状態が続いていた。遊びがてらでHeadmap Calendarを追加したのだが、Headmap Calenderがうまく動かないという状態であったのです

https://alis-programming-event.firebaseapp.com/

開発環境

開発ではGoogle Chromeで動作確認を行いDeployを行っていたのだがDeployしてiPhoneで確認してみたらちゃんとうごいていない。

iPhoneでSafariではなくChromeを使って動作確認してみても同様にうごかない。Safari依存ではなくiOS依存？結構困ってしまった。

AndroidやPCでみるとなんにも問題がないのです。結構こまってしまいました。だいたいiPhoneのSafariにはConsoleはないのだからデバックの手法がかぎられてしまう。

なんとかならないかいろいろやってみたらバグがPCで再現できました。

その方法は...

MACのSafariの開発モードを使用する

MACのSafariのSafari -> 環境設定 ->詳細で「メニューバーに”開発”を表示する」の最下部にあるチェックボックスをオンにすると開発モードが使えるようになります。

これで開発がバーに表示されます

Webインスペクターを表示を選択するとGoogle Chromeで用意されているのと類似の開発者用の機能が開きます。最初はもしかしたら下部にでてくるかもしれませんが、表示の仕方のボタン[][]みたいなのをおせば右に移動できるばすです

これで問題を追求するツールを得ることができました

直面したバグは、少し寝かして本日解決に至りました。iPhoneでの日付の扱い方に起因するバグのようでした。iPhoneにバグがあるというわけではなく、データの扱い方の違いなのかもしれませんが、やるせなかったです。

ちなみにレスポンシブモードというものがあり、開発のメニューから選択するとデザインのチェックがとても効率的に行えます。Xcodeのシュミレータみたいで便利ですね。

まとめ

iPhoneだけでうまくいかない。そういうときはSafaliの開発モードを活用しましょう。機種依存はWebアプリでも起こりうるようです。フロントエンドも奥が深いですね。

スワイプで気になるAV女優を探すことができる「AVキャッチャー」というサービスをリリースしました。

2020-01-16T22:04:03+09:00

crieitでの初めての投稿になります。
今回、スワイプで気になるAV女優を探すことができる「AVキャッチャー」というサービスをリリースしたので、集客も含めて知見の共有ができればなと思い、記事を書いてみました。

どんなサービス？

自分の好みを入力し、気になる女優をスワイプで探すことができるサービスです。
スワイプすることによって、女優が出演する作品も簡単に探すことができるようになっています。

https://av-catcher.web.app/

登録不要なので、気軽に触ってみてください！

なんで作ったの？

最近のAV女優って、めちゃくちゃ可愛い人が多いです！
もっとたくさんの人に知ってもらいたいと思い、作ってみました。

どんな構成？

アプリ自体はReactで作成し、firebaseでhostingしています。
また、データの永続化にはfirebaseのfirestoreを使用し、アプリからデータを取得する際はfirebaseのcloud functionsを通して取得するような構成になっています。

データはどのように取得しているの？

今回は、FANZAが公開している情報を元に、アプリを作成しています。
FANZAでは、月間のDVD売り上げランキングを公開しているので、そちらのページから人気の女優名を取得し、FANZAが公開しているAPIを使って、詳細情報と商品情報を取得するようにしています。
スクレイピングにはpuppeteerを使用し、firebaseのfunctionsを定期実行することによって、日時でデータを更新するようにしています。

作ってみた感想

やはり自分の好きなことだと、夢中になって作れます。
また、firebaseが非常に便利なため、簡単なアプリであれば短期間で作りきることができるようになりました。
これも、近年の個人開発ブームを加速させている要因の一つになっているのではいかと思います。
自分は個人開発が大好きなので、この記事がどなたかの個人開発の背中を押せたら幸いです。

リリースしてからのPVや売り上げ等は、今後の動きをみて随時更新していこうと思います。

SPAなNuxtアプリをFirebase HostingからNetlifyに移行してみた

2020-01-07T21:31:01+09:00

Netlifyがいいと聞いて、Firebase Hostingから移行してみたときの備忘録。

NetfilyのプレレンダリングがあるのでOGP芸が楽。
昔、こんな記事を書いたけど、Functionsで頑張らなくてもよくなった。

使ってみてよかったので、移行したときにやったことをまとめてみる。

移行するときにやったこと

nuxt.config.tsなどの変更

1. Nuxtなどの公式サイトを見て設定

Firebase Hostingで設定したのとかぶっているところもあり、nuxt.config.tsは変更なし。

参考: Netlify へデプロイするには？ - NuxtJS

2. _redirectsファイルの作成

Netlifyでは、index.html以外は404になるので、
SPAの場合はstatic/_redirecsというファイルを作成して、
以下の内容を記載しておく。

/*    /index.html   200

参考] Rewrites and proxies | Netlify Docs

3. Netlify側の設定

あとは、Netlifyにアクセスして、「SPA モードで生成されたサイトの場合」にも書いてあるとおりの内容をNetlifyの設定に入力すればOK。

迷わなければ、5分くらいでできて、masterにpushと更新される(´ω｀)

プレレンダリング

ベータ版だけど、Netlifyでプレレンダリングしてくれる機能がある。

この記事に書いてある感じで、
「FunctionsでheadだけのHTMLを生成→リダイレクト」
としていたのが不要になる感じ。

Netlifyの画面で設定

設定は簡単で、Netlify上で設定画面で有効化すればOK。
参考: Prerendering | Netlify Docs

その他の修正点

あとは、以下の修正。

OPGのためにrouterでリダイレクトしていた設定を削除
各ページでメタ情報を適切になるように変更

また、上で書いたとおり、static/_redirecsで

/*    /index.html   200

これを設定しておかないとボットがアクセスしたときに404になってOGPがでない。。

(これに気づかずかなりハマった。。)

小ネタ: プレレンダリングの結果を確認する

プレレンダリングするかどうかは、UAを見て判断しているらしく、

UAを指定してすると、プレレンダリングされた結果を確認でき、
UAを指定してないと、プレレンダリングなしの結果になる

curlだとこんな感じで、-A twitterbotを指定するとよい。

$ curl -A twitterbot https://example.com/hoge/fuga -o fuga.html

参考: [Common Issue] Understanding and debugging prerendering

毎回、Twitter Card Validatorで確認するのはめんどくさいので、この方法だと便利。

ページが存在しないURLの対応

積読ハウマッチでは、少し特殊なことをしていて、
一部のURLはheadだけのHTMLしか存在しないページがいくつかある。

なので、その部分を修正していく。方法としては以下の感じ。

nuxt.config.tsでrouterに、クエリパラメタ付きでリダイレクトを追加する
- リダイレクトとエイリアス | Vue Router
asyncData()でクエリパラメタを受け取り、created()で削除
- this.$router.push({ query: {} });
- Vuejs vue-router クエリパラメータの一部だけを取り除く - SIerだけど技術やりたいブログ

動的なサイトマップの対応

書籍やユーザのページなどは日々増えていくので、
サイトマップも動的に生成するようにしている。

Hostingの場合はFunctionsを呼び出せたけれど、
Netlifyに移行すると、それができないので対応が必要。

netlifyの_redirectsを使って直接Functionsへリダイレクトする方法で対応した。

こんな感じで各URLを該当のFunctionsにリダイレクトさせておく。

/sitemap  https://us-central1-.cloudfunctions.net/sitemap
/*        /index.html   200

sitemap-moduleだとダメだった...

sitemap-moduleで動的なページの対応方法も乗っているが、
SPAなのでgenerateされてしまう...

参考

カスタムドメインの設定

Netlifyの設定画面に従い、カスタムドメインを設定していく。

ALIASを設定するようにいわれるが、
お名前ドットコムはALIASを設定できないらしいので、
NetlifyのDNSを使う形で対応

参考にした記事でも書いてあるとおり、
Aレコードでもできるが、CDNを活用できないらしいので同様の対応

あとは、設定画面にも書いてあるとおり、
*.netlify.comから設定したドメインへリダイレクトを追加しておく。

[https://tsundoku.netlify.com/*](https://tsundoku.netlify.com/*) https://tsundoku.site/:splat 301!
/sitemap  https://us-central1-.cloudfunctions.net/sitemap
/*        /index.html   200

これでリダイレクトされるようになるので、あとはDNSの反映を待てばOK！

以上!!

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

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

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

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

参考にしたサイト

めけぽんビンゴがバズって3万円請求された件について

2020-01-06T09:30:57+09:00

従量課金地獄へようこそ！！！

まいど、弓矢です。めけぽんビンゴを作った、個人開発大好きエンジニアです。

今日の話は従量課金です。
従量課金とは、使った分だけ課金する仕組みです。上限はありません。
サービスを作る際、人気が出る確証はないけど一発狙っていきたい場合に大変ありがたい仕組みです。

しかしながら、設計を一つミスすると恐ろしいことになります。
課金は青天井。際限なく請求されます。

その結果、1日で3万円請求されました。
ちなみに広告をつけてなかったので収益は0円です。純粋に3万円の赤字です。

というわけで今回は従量課金のちょっと辛い話をします。

めけぽんビンゴ、リプレイス計画

Twitterをやりこんでいるオタクなら、「めけぽんビンゴ」を見たことがあるのではないでしょうか。
このサービスは私が高専生だった頃に作ったサービスです。
学生時代に作っただけあって、ソースコードはぐちゃぐちゃで、もはや解読するのが難しいレベルです。
お見せするとこんな感じです。そのまんまコピペしてきました。


';
        echo '

' . SITE_TITLE . 'へようこそ！
    
        ' . SITE_TITLE . 'は簡単にビンゴが作成・プレイできるサービスです。作成にはツイッターのアカウントが必要になります。

        公式ツイッターアカウントは@mekemeke_ponです。人気のビンゴをツイートしています。
        現在サイト移行準備中です。新規でカードは作成できません。


        
            
        
    
';
        $this->Adsense_square();
......

エンジニアなら、これがクソコードであることがわかるでしょう。
生PHP、しかもechoでHTML書いてました。当時の私にはそういう実装しかできなかったのです。

おまけにサーバの負荷がものすごく高くなる実装がされていました。
さくらのクラウドを使用していたので、普段は月4000円くらいのスペックで動かして、バズったときは手動でスペックを高いほうに変更する、という運用をしていました。

さくらのクラウド：
IaaS型クラウドサービス。
つまるところ、あとからスペックを自由に変えられるレンタルサーバーです。スペックが高いとかかる料金も高くなります。

このアナログな運用では、以下のような問題がありました。
* バズに感知できないとサーバが落ちてしまう
* スペック変更時にサーバの電源を切る必要があり、手間がかかる

解読不能のままでは修正や更新もままならないですし、突発的なバズが発生するめけぽんビンゴでは手動スペック変更での運用は厳しいものがありました。

というわけで、先月 Firebase + Netlify + SPA(Nusx.js) で大幅リプレイスを行いました。

Netlify：
静的サイト専用のホスティングサービスです。つまるところ、難しいこと（PHPとかCGIとか）はできない基本無料のレンタルサーバーです。ある程度は無料で、あんまり使いすぎると費用が発生します。
Firebase：
今回の主人公の従量課金バックエンドサービスです。つまるところ、データを保存できる基本無料のサービスです。ある程度は無料で、一定回数以上の処理は、処理回数分費用が発生します。
SPA：
index.html一枚だけで作るWebサイトです。JavaScriptというプログラミング言語で、ページの中身を書き換えています。

Netlifyで、いくらアクセスが発生しても大丈夫になりました。
Firebaseで、どれだけデータ書き込み（めけぽんビンゴの場合はプレイ）がされても重くならなくなりました。
SPAで、プレイ後のページ遷移が重いなんてことがなくなりました。

運営者ギルドの皆様にバグバッシュをしてもらい、公開します。ちょっと事故を起こしたので、ちゃんと公開できたのは12月30日のことでした。

その時点ではAdsenseのサイト審査が通ってなかったので、Adsense広告を貼るのは後にすることにしました。
あの時の私は、こんなにすぐバズるとは思っていなかったのです……

Adsense：
Googleの自動広告。つまるところ、アフィみたいなモンです。

来たる、バズ　～リアルタイム閲覧者数8000人～

公開できたので、今までのビンゴの中でも人気が高かった都道府県ビンゴの完全版「行ったことある都道府県４７！」をサクラで投稿し、年越しをしました。

そして年明け。
毎年正月にバズるしたためったーは、ツイッターのトレンド30位くらいまで浮上する程度に健闘してくれました。（余談ですが、私はしたためったーを心の中で「お年玉」と呼んでいます。）
正月はみんなテレビを見ているため、トレンドがほぼテレビ番組関連です。とにかく母数が大きいので、他のワードはなかなかトレンド浮上できません。
めけぽんビンゴも特に浮上しないだろうと高をくくっていました。
しかし駅伝の復路が盛り上がる1月3日のこと。

2日時点でトレンド入りしない程度のバズだっためけぽんビンゴが、トレンド3位にまで浮上しました。

その時のリアルタイムの閲覧者数がこちら。

私が知ってる中では、過去最高記録です。過去トレンド1位を取ったときも、ここまで人は来ていません。
正月休みでやることがない人が多かったことが、一番の要因でしょう。
それに加えて『いくらアクセスが発生しても重くならなくなった』『どれだけデータ書き込みがされても重くならなくなった』ということも、爆発的なアクセス増加に加担しているかと思われます。

見たことのない数字に対して、多少不安になりながらも興奮して眺めていました。

立ち込める、暗雲　～読み取り1.5億回～

爆発的バズが収まった1月4日。
1月3日分のFirebase（Firestore）の利用状況を確認しました。

書き込み80万に対して、読み取り1.5億回。億という数字に対してイマイチイメージがわきませんが、読み取りが多すぎるような感じがします。書き込みが1回行われる間に読み取りが187.5回行われる計算です。

設計を見直して、ある事に気が付きます。
プレイ後に、更新データをリアルタイムで取得するようにしていたのです。
「プレイ後のパーセンテージがリアルタイムで変わったらおもろいやろ」程度の気持ちで実装したものでした。
しかしバズっているビンゴは1秒に何回もプレイされて、そのたびにデータが更新されます。さらに、ページを移動してもリアルタイム取得は止まりません。
その結果、大量のリアルタイム取得が発生し、読み取り回数が億を突破するという馬鹿げたことになったのでしょう。
（この不具合は現在は修正済みです。）

襲い来る、請求　～意外と安かった～

そして気になる料金。
1月2日時点のPV数が7万、1月3日時点でのPV数が72万。一体どんな恐ろしいことが起きるのか……
1月3日の請求額は2日後の1月5日に確定します。

念のためにさらに1日置いて1月6日朝。震えながら確認したところ……

い、意外と安い……！？（2万円の赤字だけど）
ちょっと信じられなかったのでFirebaseの使用量から計算してみたのですが、だいたいあっているようです。

しかし安いと言っても2万円です。1日で2万の請求は個人開発史上最大のマイナス。
中間層のお年玉総額程度の赤字ですが、学生の頃なら痛かったと思います。

ここまでFirebaseの話ばかりしましたが、めけぽんビンゴで使用している従量課金サービスはもう一つあります。
Netlifyです。
無料の上限がかなり高いので無料のサービスあつかいされていますが、これだけPVがあると流石に有料になるようです。
Netlifyから「無料枠超えたよ！」と言うメールが来たので、確認してみました。

80ドル。現在のレートだと8643円です。

と言うわけで合計で約3万円の請求がきました。
富裕層のお年玉総額程度の赤字ですが、学生の頃なら超痛かったと思います。

反省、そしてまとめ

今回の反省点は、バズったときのことを考えない設計をしてしまったことでしょう。
不幸な点として、Adsenseの審査が間に合わなかったこともあげられます。Adsense広告があったのなら、このくらい取り返してくれていたでしょう。

よかった点としては、Firebaseは普通に使えば割と安上がりと言う学びがありました。
1日72万PVでゴリゴリに画像も生成をしなおかつ不具合で無駄な呼び出しが大量に発生しているのに、たったの2万です。不具合修正後はもうちょっと安く済むでしょう。
Netlifyについてはプリレンダリングが強いので、このまま使いたいと思います。（なんだかんだ無料枠が大きいので、請求が発生するのはそう滅多にないはず。）

エンジニア界隈ではFirebaseがもてはやされていますが、ひとつ設計を見誤ると地獄が発生します。
エンジニアの皆様、とくにお金を持っていない個人開発者の学生の方。設計には気を付けましょう！！！

そしてサービス利用者の皆様。いつもありがとうございます。
今回私はヘマをしでかしてますが、バズったことは悪いことではありません。いいことです。
素敵なサービスを見つけたらバズらせに加担していきましょう！！！

脚注・リンク

お年玉総額について：
想像です。ソースはありません。

地獄の大先輩：
Firebaseの設定を間違えて72時間で300万円以上請求されてしまったウェブサービス

Firebase フロントエンド(Vue.js)/Cloud Functions を同一docker-composeで実行する際に感じたこと

2019-12-30T14:15:44+09:00

はじめに

2019/12/30現在において、Firebaseを開発する際に生じる不都合の一つとして、node version管理があると思います.

Cloud Functionsの開発において、nodeのバージョンはversion8、あるいは10がサポートされています.

Cloud Functions ランタイムに関数をデプロイするには Firebase CLI が必要です。Node.js バージョン 8 と 10 がサポートされています。Node.js と npm をインストールする場合は、Node Version Manager をおすすめします。
https://firebase.google.com/docs/functions/get-started?hl=ja

つまり、こんなことが頻発します.

[dorakueyon]% yarn build
yarn run v1.19.2
error functions@: The engine "node" is incompatible with this module. Expected version "8". Got "10.15.3"
error Commands cannot run with an incompatible environment.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

このように、異なるversionが依存する開発では、その依存性をDockerに閉じ込めることで幸せになれます.

参考として、githubにcodeを置かせていただきました.
- github.com/dorakueyon/vue-firebase-cloud-function-docker-starter

Vue.js + Cloud Functionsのフォルダ構成

Docker化する前に、プロジェクトを作成した上でフォルダ構成をみてみます.

Vue.js + Firebaseプロジェクト作成

$ vue create project-name
$ firebase init

フォルダ構成 (node_modules配下を除いています)

.
├── README.md
├── babel.config.js
├── firebase.json
├── functions
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   ├── src
│   └── tsconfig.json
├── node_modules
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
├── src
│   ├── App.vue
│   ├── assets
│   ├── components
│   ├── main.ts
│   ├── router
│   ├── shims-tsx.d.ts
│   ├── shims-vue.d.ts
│   └── views
├── tsconfig.json
└── yarn.lock

FrontとCloud Functionsを開発する場合、プロジェクト直下と./funcions直下とで開発環境が分かれます.

それぞれにDockerfileを配置した上で、プロジェクト直下にdocker-compose.ymlを配置します.

Dockerファイルを追加したフォルダ構成 (node_modules配下を除いています)

.
├── Dockerfile <-
├── README.md
├── babel.config.js
├── docker-compose.yml <-
├── firebase.json
├── functions
│   ├── Dockerfile <-
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   ├── src
│   │     ├── index.ts
│   │     └── services
│   │         └── project-name -> ../../../src/services/project-name <- シンボリックリンク
│   └── tsconfig.json
├── node_modules
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
├── src
│   ├── App.vue
│   ├── assets
│   ├── components
│   ├── main.ts
│   ├── router
│   ├── services
│   │   └── project-name <- シンボリックリンク先
│   │       └── constants.ts
│   ├── shims-tsx.d.ts
│   ├── shims-vue.d.ts
│   └── views
├── tsconfig.json
└── yarn.lock

Docker化

Docker化にむけて、下記の要件があります.

プロジェクト直下のfirebase関連ファイル(firebase.json, .firebaserc)を、./functions側でも参照したい
./functions側からプロジェクト直下の定数やtypeをシンボリックリンクで参照する場合がある

上記を念頭に、Dockerfile/docker-compose.ymlを作成します.

プロジェクト直下のDockerfile

こちらは特に考えることはありません

FROM node:12-alpine

ENV WORKDIR /work
WORKDIR $WORKDIR

COPY package.json $WORKDIR
RUN yarn

COPY tsconfig.json $WORKDIR
COPY *.config.js $WORKDIR/
COPY public $WORKDIR/
COPY src $WORKDIR/src

EXPOSE 8080
CMD yarn serve

./functionsのDockerfile

./functions/Dockerfileと、./docker-comose.ymlを比較しながらご確認ください.

WORKDIRを/work/functionsとする
./functions直下のファイルCOPYは、コピー元をプロジェクト直下からの相対パスで指定する
プロジェクト直下のファイルCOPYは、コンテナの/work配下に設置する

FROM node:8-alpine

ENV WORKDIR /work/functions
WORKDIR $WORKDIR

COPY ./functions/package.json $WORKDIR
RUN yarn
# firebase
RUN yarn global add firebase-tools

COPY ./functions/tsconfig.json $WORKDIR
COPY ./functions/lib $WORKDIR/lib
COPY ./functions/src $WORKDIR/src
# # for symbolic link (./functions/src/services/project-name)
# COPY ./src/services/project-name /work/src/services/project-name

# firebase
COPY firebase.json /work
COPY .firebaserc /work
# COPY ./functions/.runtimeconfig.json $WORKDIR # if needed
# COPY ./functions/credentials $WORKDIR/credentials # if needed

# settings for runtime emulator
ENV HOST 0.0.0.0
EXPOSE 5000

EXPOSE 9005

プロジェクト直下のdocker-compose.yml

上記Cloud FunctionsのDockerfileにあわせるためbuild:のcontext, dockerfileを別に指定する
symbolic linkされている(プロジェクト直下にある)実体ファイルの変更もfunctions側のdockerに反映させるため、./src:/work/srcを追加

version: '3'

services:
    main:
        build: .
        container_name: front
        volumes:
            - ./public:/work/public
            - ./src:/work/src
        ports:
            - 8080:8080
        tty: true
        command: yarn serve

    functions:
        build:
            context: ./
            dockerfile: ./functions/Dockerfile
        container_name: functions
        volumes:
            - ./functions/lib:/work/functions/lib
            - ./functions/src:/work/functions/src
            - ./src:/work/src # for symbolic link
        # environment:
        #    - GOOGLE_APPLICATION_CREDENTIALS=./credentials/firebase-adminsdk.json
        ports:
            - 5000:5000
            - 9005:9005
        tty: true

開発の場合

開発環境立ち上げます

$ docker-compose build && docker-compose up

その後の開発は下記のようにすすめます

front

http://localhost:8080にVue.jsプロジェクトがホットリロードされます

Cloud Functions

こちらは多少面倒ではあります

dockerコンテナに入る
firebase loginしていなければfirebase loginを実施
firebase serveやfirebase functions:shellなどでdebugging

以下 docker exec functions -it sh してコンテナ内で

$ firebase login # if you are not logged in.
$ firebase serve
$ firebase functions:shell

Cloud Functionsのデバッグについてはまだペインが多いです..

関数をインタラクティブにテストする(Firebase official)

firebase loginの認証情報を永続化(都度fireabase loginしたくない)人は下記のサイトが参考になるかもしれません(試していません..)

[Firebase] Cloud Functionsで消耗したくない人のために、開発環境のベストプラクティスをまとめていったらDockerに行き着いた話

deploy

github actions/ circleCIなど利用したほうがよいでしょう.

おわりに

少し強引な形となってしまいましたが、Dockerの恩恵をうけることができる状態までできました.
ただし、./functions/Dockerfileのフォルダのコンテキストが親階層直下にある点に気持ち悪さがあります.

ここの気持ちわるさの解消は今後の課題とします.

Nuxt+Firebaseでセッション管理: PWA(Service Worker)編

2019-12-29T19:07:03+09:00

FirebaseとSSRなNuxt.jsでアプリを作っていて、
クライアント側で認証チェックするとFirebaseの初期化などでラグが...
サーバ側で認証情報とかを取得してもう少しなんとかできないかなと。

まだベータっぽい?けど、公式の以下の内容を試してみたときの備忘録。

Service Worker によるセッション管理 | Firebase

よく出てくる言葉

単語はよく聞くけど、ちゃんと見てなかったので、ざっくりとしたまとめ

PWA: ネイティブアプリみたいなUXを提供するWebアプリ
- Progressive Web Apps | Google Developers
Service Worker: PWAを実現するための基盤技術。独自のライフサイクルを持ってる
- Service Worker の紹介 | Web Fundamentals | Google Developers
Workbox: PWAでよく使うコード(ボイラープレート)やベストプラクティスを提供するライブラリ
- Workbox | Google Developers
Nuxt PWA: NuxtでPWAするときに使うプラグイン。workboxを使ったService Worker(sw.js)とかを生成してくれる
- ⚡ Nuxt PWA

Nuxt PWAを使ってみる

インストール

$ npm install @nuxtjs/pwa

設定

設定は簡単。modulesに@nuxtjs/pwaを追加するだけ。

// nuxt.config.ts
import { Configuration } from "@nuxt/types";

const config: Configuration = {
  // ...略
  modules: [
    // ... 略
    "@nuxtjs/pwa",
  ],
  // ...略
};

export default config;

Firebase Authと組み合わせる

このあたりを見つつ、Firebase Authの情報を扱えるようにする。
- Service Worker によるセッション管理 | Firebase
- Firebase (Hosting × Functions) × Nuxt.js (universal) でユーザ認証のベストプラクティスを探る旅その２ - Qiita

流れ的には、以下の通り。

Firebase Auth用のService Workerの作成して、リクエストにIDトークンを付与するように変更
作成したService Workerを使うよう、nuxt.config.tsに設定を追加

Firebase Auth用のService Workerの作成

長めだけど、ほぼ公式ドキュメントのまま。

// ~/static/sw-firebase-auth.js

// firebaseを初期化
firebase.initializeApp({
  apiKey: /* API_KEY */,
  authDomain: /* AUTH_DOMAIN */,
  databaseURL: /* DATABASE_URL */,
  projectId: /* PROJECT_ID */,
  storageBucket: /* STORAGE_BUCKET */,
  messagingSenderId: /* MESSAGING_SENDER_ID */,
  appId: /* APP_ID */,
  measurementId: /* AUTH_DOMAIN */
});

// onAuthStateChanged()で現在のuserからidTokenを取得
const getIdToken = () => {
  return new Promise((resolve, reject) => {
    const unsubscribe = firebase.auth().onAuthStateChanged(user => {
      unsubscribe();
      if (user) {
        user.getIdToken().then(
          idToken => resolve(idToken),
          error => resolve(null)
        );
      } else {
        resolve(null);
      }
    });
  });
};

// URLからルートのURLを取得する処理
const getOriginFromUrl = url => {
  // https://stackoverflow.com/questions/1420881/how-to-extract-base-url-from-a-string-in-javascript
  const pathArray = url.split("/");
  const protocol = pathArray[0];
  const host = pathArray[2];
  return protocol + "//" + host;
};

/**
 *  Service Workderのライフサイクルでfetchしたときの処理
 */
self.addEventListener("fetch", event => {

  // リクエストをラップして、ヘッダにFirebase AuthのIdTokenを追加する処理
  const requestProcessor = idToken => {
    let req = event.request;
    // URLを取得して、httpsもしくはlocalhostかなどをチェック
    if (self.location.origin == getOriginFromUrl(event.request.url) &&
      (self.location.protocol == "https:" || self.location.hostname == "localhost") &&
      idToken
    ) {
      // ヘッダ情報をクローンする
      const headers = new Headers();
      for (let entry of req.headers.entries()) {
        headers.append(entry[0], entry[1]);
      }
      // クローンしたヘッダにFirebase AuthのIdTokenを追加
      headers.append("Authorization", "Bearer " + idToken);
      try {
        req = new Request(req.url, {
          method: req.method,
          headers: headers,
          mode: "same-origin",
          credentials: req.credentials,
          cache: req.cache,
          redirect: req.redirect,
          referrer: req.referrer,
          body: req.body,
          bodyUsed: req.bodyUsed,
          context: req.context
        });
      } catch (e) {
        console.error(e);
      }
    }
    return fetch(req);
  };

  // 上の関数を使って、全リクエストでIdTokenの取得し、Firebase AuthのIdTokenを追加ようにする
  event.respondWith(getIdToken().then(requestProcessor, requestProcessor));
});

/**
 *  Service Workderのライフサイクルでactivateしたときの処理
 */
self.addEventListener("activate", event => {
  event.waitUntil(clients.claim());
});

やっていることは、以下のような感じ。

リクエストするときに、
現在のユーザからIDトークンを取得して
IDトークンをリクエストヘッダーに追加する

ヘッダーにIDトークンが付与されているので、
サーバ側でそれを見て、認証済みかをチェックする。

nuxt.config.tsへの取り込み

作成したサービスワーカを使うように、nuxt.config.tsに設定を追加する。
ドキュメントだとこのあたりを参照。

// nuxt.config.ts
import { Configuration } from "@nuxt/types";

const config: Configuration = {
  // ...略
  modules: [
    // ... 略
    "@nuxtjs/pwa",
  ],
  workbox: {
    // 追加するスクリプトを指定。
    // バンドルされないので、CDNのfirebase-appを追加しておく。
    importScripts: [
      "https://www.gstatic.com/firebasejs/7.6.1/firebase-app.js",
      "https://www.gstatic.com/firebasejs/7.6.1/firebase-auth.js",
      "sw-firebase-auth.js"
    ],
    // 開発中でもsw.jsが生成されるように設定。
    dev: process.env.MODE != "production",
  },
  // ...略
};

export default config;

nuxtServerInitなどで認証状態をチェックする

IDトークンもJWTデコードすると、UIDを取得できるけれど、
有効かどうかをfirebase-adminでチェックする必要がある。

なので、まずは、firebase-adminのインスタンスを初期化するファイルを用意。

// ~/utils/firebaseAdmin.ts
let admin;

if (process.server) {
  admin = require("firebase-admin");
  if (!admin.apps.length) {
    const serviceAccount = require("./path/to/your/key.json");
    admin.initializeApp({
      credential: admin.credential.cert(serviceAccount),
      databaseURL: "https://your-database-url.firebaseio.com"
    });
  }
}

export default admin;

次にこれを使って、以下をしていく。

リクエストヘッダからIDトークンを取得し、
firebase-adminを使ってIDトークンの有効性を確認

以下は、vuex-module-decoratorsを使ったnuxtServerInitでチェックするサンプル。

// ~/store/index.ts

import { Context } from "@nuxt/types";
import { ActionContext } from "vuex/types";
import { ActionTree, Store } from "vuex";
import { initialiseStores } from "~/utils/store-accessor";

export const state = () => ({});
export type RootState = ReturnType;

const initializer = (store: Store) => initialiseStores(store);
export const plugins = [initializer];

export const actions: ActionTree = {
  async nuxtServerInit(
    context: ActionContext,
    server: Context
  ) {
    // requestのAuthorizationからIDトークンを取得
    const authorizationHeader = req.headers.authorization || "";
    const components = authorizationHeader.split(" ");
    const token = components.length > 1 ? components[1] : "";
    if (!token) return;

    // firebase-adminの初期化
    const admin = require("~/utils/firebaseAdmin").default;
    if (!admin) return;

    // IDトークンの検証: 有効期限などをFirebaseでチェック
    const decodedClaims = await admin.auth().verifyIdToken(token);

    // 検証結果からUIDを取得
    const uid = decodedClaims.uid;

    // TODO: 認証状態に応じてなにかする
  }
};

export * from "~/utils/store-accessor";

firebase-adminを取得する部分を

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

としていたり、if (process.server)やif (!admin.apps.length)などのチェックをせずにいたら、
クライアント側でもバンドルされていて、うまく動かいない状態に...

注意点

これで認証が必要なページでもいい感じSSRできた気がする(´ω｀)

ただ、課題が残っていて、スーパーリロード/ハードリロードすると、
Service Workderを介して、リクエストされないので、ヘッダに認証情報が付与されない...

ログを見ていると、スーパーリロード時には、描画されたあとに、Service Workderの登録されているよう。

そういった場合でも、利用したい場合には、従来のセッションCookieを利用する方法がよいかも？

セッション Cookie を管理する | Firebase

(もし良い方法があれば、教えてほしいです...)

おまけ: Service Workerのライフサイクル

ここに書いてあった。
- Service Worker の紹介 | Web Fundamentals | Google Developers

以上!!

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

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

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

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

参考にしたサイト様

NuxtでFirebase AuthのトークンをCookieに入れたり出したりする

2019-12-29T11:21:19+09:00

NuxtのSSRで認証したいなと思ったら、こんな記事を見つけたので、試してみたときの備忘録。

SSRモードのNuxtでのFirebase認証 - Qiita

結果、UIDは取得できるけど、firebase-adminで検証が必要っぽい...

インストール

cookieを扱うライブラリはいろいろあるけど、
universal-cookieがよさそうだったので、これを使ってみる。

$ npm install universal-cookie jwt-decode

使い方

import { IncomingMessage } from "http";
import firebase from "firebase
import jwtDecode from "jwt-decode";
import Cookies from "universal-cookie";

const KEY_TOKEN = "access_token";

/**
 * firebase.Userからトークンを取得して、Cookieに保存
 */
export async function setCookie(currentUser: firebase.User) {
  // firebase.UserからidTokenを取得
  const token = await currentUser.getIdToken(true);

  // 新規追加するときは、引数なしでnew Cookies()
  const cookies = new Cookies();
  //  Cookieに保存
  cookies.set(KEY_TOKEN, token);
}

/**
 * Cookieにあるトークンをデコードして、UIDを取得
 */
export function getCookie(req: IncomingMessage) {
  if (process.server && process.static) return;
  if (!req.headers.cookie) return;

  // requestヘッダーのCookieを取得する場合は、引数に追加
  const cookie = new Cookies(req.headers.cookie);
  const token = cookie.get(KEY_TOKEN);
  if (!token) return;

  // jwtDecodeでトークンをデコードする
  const decodedToken = jwtDecode(token);
  if (!decodedToken) return;

  return decodedToken.user_id;
}

以上!!

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

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

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

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

参考にしたサイト様

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

2019-12-12T22:32:10+09:00

Googleから怪しげなメールが届いた。本文を見てみると「Google Cloud Platform または API プロジェクト（プロジェクト名）の認証情報が不正使用された可能性があります」とのこと。

ドキッとした。クラウド破産…！？

調査

メール内の最初の方に、ここで一般公開されている、というURLが書かれていた。そこにアクセスしてみる。GitHubだった。するとたしかに僕のサイトっぽい名前のファイルがある。中身はバイナリファイルだったが、どうもここにAPIキーが含まれているらしい。

料金の確認

ちなみにプロジェクトはこのCrieitのプロジェクト。メールに色々と確認手順が書かれていたが、とりあえず読まずに料金がどうなっているだろうかを急いで確認してみた。今月の料金は……10円。とりあえず問題はなさそうでホッとした。が、そうこうしている間に何かしら利用されて今後料金が加算されていってしまう可能性がある。

何のAPIキーかを確認

細かくメールを見たかったがメール内にAPIキーが書かれていたので、ひとまずGCPのダッシュボードでそれが一体何のAPIキーなのかを調べてみることにした。

確認方法はGCPコンソールの「APIとサービス」→「認証情報」。ここでAPIキーの一覧を見ることができる。

問題となったのはこの画像の右下端に表示されている Browser key (auto created by Google Service) というもの。なんとなく見覚えがある。だいたいFirebaseのプロジェクトに関連付けた時に勝手に作られているものがこんな感じだったような気がした。Browser keyということなのでそれっぽい。

どこで使っているかを確認

とにかくどこで使っているかを確認してみることに。本番サーバーにログインし、.envを開いて検索してみた。しかし見つからない。

ということでローカル上でプロジェクトをVSCode開いて検索してみる。すると見つかった。やはりFirebaseのAPIキーだった。これは公開しないとどうしようもないのと、ちょっとした機能で使っているだけのため環境分けをするのも面倒だったので直接コミットしてある。ということでそれを見つけた。

そもそもFirebaseのAPIキーとは

Firebaseのプロジェクトを作ったことがある方であればよく見るものだと思うが、こういった設定。これのapiKeyというところが今回問題となったAPIキー。

僕が普段良く作っているWebアプリケーションの場合、この設定はブラウザで動作するもののため、そもそも公開しなければならない。そのため後悔自体は問題がないはず。

何が問題か

何が問題かというと、適切なセキュリティ設定が行われていない状態だと問題となる可能性がある。無料のSparkプランや月額制のFlameプランであればさほど問題にはならない。あるとしてもリソースを利用しつくされてサービスが止まるだけ。

問題となるのは従量制のBlazeプラン。今回のCrieitのアプリケーションはこれだった。この場合、従量制なのでいたずらで無限ループなどをされると恐らくとんでもない料金になってしまう可能性がある。とはいえ僕の場合Realtime Databaseと匿名認証を有効化していただけなのでさほど問題にはなりにくかったかもしれない。Firestoreを利用している場合は危険な可能性がある。

セキュリティの設定

恐らく、SNS認証＋Firestoreのセキュリティルール設定済み、であれば問題にはならないだろう。問題になりそうなのは、匿名認証＋Firestoreという場合。SNS認証は認証可能なURLを設定できるため、その設定さえしておけば不正利用は難しい。しかし匿名認証はURL指定ができないため、APIキーを利用すれば誰でもアプリケーションを動かすことが出来てしまう。このパターンだとまずそう。ちなみに今回はこのパターン。

ではこの場合どうすればいいのか。メールにも書かれていた。

API キーに API キー制限を追加します（該当する場合）。

そう、先程スクショで説明した認証情報のページで、該当のAPIキーをクリックすると認証情報の設定ができる。ここでAPIキーの利用制限の設定ができる。GCPで直接自分で作ったキーの場合はできることを知っていたのだが、なんとなくFirebaseが勝手に作ったものは同じものという認識がなかったので気づかなかった。

とりあえず、リファラーの設定をしておいた。

何か間違っていたら機能が止まってしまうかもしれないが、今回は大したことのない機能のために使っているので気にせず設定した。これで一覧ページに元々出ていたアラートアイコンも消えた。

まとめ

そもそもこの設定はFirebaseの方で出来た方がいいんじゃないか…と常々思っていた。わりとこのあたりの事を知らない方もいるのでは。

とにかくクラウドの利用は気をつけよう。そういえば料金アラートは設定していたので何にしろ何かあってもすぐ気づけたかもしれない。

細かく試して書いたわけではないため、もしこの記事で間違えている情報などあれば情報提供いただけるとありがたいです。

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

2. セットアップ

2-a. 秘密鍵の取得

Firebaseコンソールから秘密鍵を生成して配置してください。

左上の歯車から「プロジェクトの設定」をクリックし、

「サービスアカウント」タブの下にある、「新しい秘密鍵を生成」をクリックすると、
秘密鍵のjsonファイルをダウンロードできます。

この例では、./credential.jsonとしてます。

2-b. 設定ファイル(.env)の作成と設定

env_sampleという設定ファイルの雛形があるので、.envにコピーしてください。

$ cp env_sample .env

コピーしたら、.envを開いて、配置した秘密鍵の相対パスを設定してください。

  # Copy this file with file name '.env'

  ## ex. CREDENTIAL_PATH=./credential.json
- CREDENTIAL_PATH=YOUR_CREDENTIAL_PATH
+ CREDENTIAL_PATH=./credential.json

これで設定はOK。

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

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

ほかの失敗談

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

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

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

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

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

「Firebase」の記事 - Crieit

【個人開発】作るのも、答えるのも簡単なWebアンケート「ankeyto」を作りました！

Windowsのnvmのnodeでfirebase-toolsを入れようとしたらUnexpected token '.' エラー

数日で有料サービスをリリースしてみた話

QnQ開発日誌 Firebaseで管理者用画面はみんなどうしているのかな

FirebaseとSSSAPIでプレスリリースを送ったサイトを記録できるWebサービスを作ってみた

QnQ開発日誌 単体テストなしで大丈夫か？

週末の時間を使って「みんなのきょうしつ」をアップデートしました。

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

好きな楽曲について語り合うウェブサービス「musico」を作ってみました。

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

iPhoneだけでWeb アプリの動作がおかしいときのデバック環境

スワイプで気になるAV女優を探すことができる「AVキャッチャー」というサービスをリリースしました。

SPAなNuxtアプリをFirebase HostingからNetlifyに移行してみた

めけぽんビンゴがバズって3万円請求された件について

' . SITE_TITLE . 'へようこそ！

Firebase フロントエンド(Vue.js)/Cloud Functions を同一docker-composeで実行する際に感じたこと

Nuxt+Firebaseでセッション管理: PWA(Service Worker)編

NuxtでFirebase AuthのトークンをCookieに入れたり出したりする

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

QnQ開発日誌単体テストなしで大丈夫か？