Firebaseの存在をフロントエンドから隠蔽するために
「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase
Cloud FunctionsをGoで書く。またはFirebaseのためのマイクロサービスアーキテクチャ - laiso
Firebase Advent Calendar 2019 の17日目です。16日目はKesin11さんの「Firebase Emulator Suiteをフル活用してTDDで開発しよう」でした。 はじめに FirebaseプロジェクトでCloud Firestoreを利用する時は通常Node.jsによるCloud Functionsでトリガーとなる処理を記述します。その他には関連するAPIサーバー、WebアプリのフロントエンドのSSR、バックエンドの非同期処理など、多くの場面でCloud Functionsが活用されています。 この開発→デプロイサイクルをお手軽に行ってくれるのがfirebase-toolsというnpmモジュールです。JavaScriptでFunctionを実装し、firebase deployコマンドを実行するだけでFirebaseプロジェクト用のCloud Funct
大量のPush通知をCloud Functions経由で送信する - BANK tech blog
こんにちは。ふぁぼ通知が好きなうなすけです。 モバイルアプリでは、Push通知によってユーザーに情報を伝えたり、行動を促したりすることが日常的に行われています。 その通知を送る対象のユーザーが数十人程度の規模なら、愚直に一通一通送信すればいいでしょうが、一気に万単位のユーザーにPush通知を送信したい場合、愚直に送信すると完了までに数時間かかることも往々にしてあります。 CASHでの大量Push通知事例 以前、ある施策のために42万件のPush通知を送る必要がありました。CASHではFirebase Cloud Messaging(以下FCM)をPush通知の送信に使用しているのですが、このとき、通知1件ごとにAPIを叩いていく方式だと送信完了に1日かかってしまうという事態になりました。 FCM Topic Messaging そのような場合に使用できるのが、Topicを用いた通知の送信で
Vue.jsのPWAでバックエンドをDjangoからFirebaseに移行した - GAミント至上主義
現在開発中のVuejsを使ったPWAで、開発当初はログインやデータの保存にDjangoを使っていたけど、ずっと気になっていたFirebaseに変更してみることにした。 2018/8/2 追記 Vue.jsを使ったPWA、yagish 履歴書リリースしました rirekisho.yagish.jp 追記ここまで クライアント側のコードはほぼそのまま流用し、機能も少なかったので、1日程度でとりあえず動いた とりあえず移行した機能は下記。 Googleログイン（Firebase Authentication） ユーザーごとのデータバックアップ＋ロード（Cloud Firestore ※まだベータ） もちろん移行できなかった、しなかった機能もある。 PDF生成サーバー（LinuxでヘッドレスChromeを使うため） アップロードされた画像をリサイズしてBase64で返すもの（Djangoのまま、こ
Typescript + React、Firebase Hosting & Functions、Github GraphQL APIを使って自分のポートフォリオサイトを作った。
構成は下記の様にした。 Typescript 2.6 & React 16.0Firebase Hosting & Cloud Function、RealtimeDatabaseGithub API v4 (GraphQL with Apollo Client)Typescript & React今JavaScriptを利用するとしたらTypescript or Flowtypeになると思う。 Flowtypeは会社で使っている & 自作のOSSで利用した事があった。 http://teitei-tk.hatenablog.com/entry/2017/06/19/192432
Firebase Functions 上に GraphQL サーバーを実装する - Qiita
この記事は１ヶ月後の自分のネタ切れにつきアドベントカレンダーの記事ということになりました Why SPA や モバイルアプリ だととりあえず Firebase Functions に graphql エンドポイントを一個マウントして金で殴ってスケールさせるところからスタートするのがいいと思います。金の弾丸というやつです。 この環境は、query と mutation は実装できるけど、 Cloud Functions のライフサイクルの都合上、 wsバックエンドのsubscription は実装できません。そこは Firestore とか使ってなんとかできるんでいいかって感じ。 自分の用途としては、Firestore の write系は一律禁止、 read 系は firebase.rules で制御しつつ subscribe して、リアルタイムではない複雑な問い合わせやロジック検証付きの副
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
