個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
StableDiffusionに対応したGakyoを雑な設計のためわずか数日で10万円くらいのクラウド利用料がかかってしまった。
はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの田村です。普段はサーバサイドエンジニアとしてFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。FAANSでは、データベースとしてGCPのサーバレスでドキュメント指向のNoSQLデータベースであるCloud Firestoreを当初採用していました。Cloud Firestoreはサーバレスなので運用負荷が掛からず、また安価でスケーラビリティにも優れたハイパフォーマンスなデータベースです。 しかし、Cloud Firestoreを使用して開発・運用していく中で直面した様々な課題からGCPのフルマネージドのリレーショナルデータベースであるCloud SQLのPostgreSQLにデータベースのリプ
はじめまして、開発部の@taikishiinoです。 2020年3月にアンドパッドにジョインし、約一年が経ちました。 現在、チャットサービスの開発・運用をするチームに所属しており、その中で最近、RDSからFirestoreへのデータ移行を行いました。 本記事では、その際の課題やそれに対して実際に行ったことなどを中心にご紹介していきます。 データ移行の背景 僕たちのチャットサービスを開発するチームでは、現在、プロダクトのデータベースをRDSとFirebase RealtimeDatabaseのミックスからFirestoreに移行する大規模プロジェクトが行われています。 旧環境「RDSとFirebase RealtimeDatabase」の課題として、 チャットのアクセスを処理しているAPIサーバーのバックグラウンド処理は複数プロダクト共通で利用しており、チャット起因で負荷が高まってしまうとい
Googleのモバイル向けNoSQL「Firestore」が秒間1万回の書き込み制限を撤廃、事実上無制限のスケーラビリティを提供。Firebase Summit 2022 Googleは10月18日に米ニューヨークでモバイル向けのバックエンドサービスであるFirebaseにフォーカスしたイベント「Firebase Summit 2022」を開催しました。 GoogleはこのFirebase Summitで、Firebaseの機能の1つとして提供されるNoSQLデータベースであるFirestoreに存在していた秒間1万回までの書き込み制限を撤廃し、事実上無制限のスケーラビリティをFirestoreで提供すると発表しました。 FirestoreはFirebaseの機能の1つとして提供されるドキュメントストア型のNoSQLデータベースです。 Firestoreには、モバイルデバイス上のローカルデ
データ統括部AI基盤部の竹村( @stakemura )です。本記事では、このたびリリースされた、自分の声をキャラクターの声に変換できるWebサービス VOICE AVATAR 七声ニーナ を支えるバックエンド技術についてお話しします。 本サービスはDelight Boardという部署横断型のプロジェクトにて、1000人を超える社員投票により自分の案がまさかの採択となったことがきっかけとなります。幸運にも、百戦錬磨のプロジェクトメンバーに助けられ今日のリリースを迎えましたが、採択当時は人脈も信用貯金も何もない入社一年目の思いつきにすぎず、言い出しっぺである自分の力不足によりタイトなスケジュールでの開発となってしまいました。本記事では、その限られた開発期間の中で、自分が何を考えて実装したかを中心にお伝えします。 サービングに求められる要件 七声ニーナの音声変換はブラウザから受け取った入力音声
こんにちは。virapture株式会社のもぐめっとです。 最近ストーリーでボケてみたのですが、このボケに気づいた人が以外に少なくてボケ力の弱さを痛感しました。みなさんはどうツッコみますか？ 本日は朝起きたらスーパー便利そうなツイートを見つけたので試しに使ってみたのでみなさんに共有いたします。 firefooとは 簡単にいうとFirestoreを操作できるGUIクライアントなんですが、firebaseのコンソールよりもより使い勝手が良く、sequelproみたいに簡単にデータが操作できるイケイケツールです。 説明するより下記動画を見てもらった方が早いですね。 セットアップ 下記からダウンロードしてインストールします。 使ってみた 起動するとログインを求められるのでログインを行います。 ログインが成功すると保持しているプロジェクトがずらりと！もうこの時点で便利すぎ。好き。 プロジェクトを開くと
こんにちは。virapture株式会社のもぐめっとです。 最近ユニクロで友達とオソロのメタモンTシャツ買いました。カワイイです。 本日はfirestore使ってて辛いよーという声をよく聞いたので、そのままfirestore使っていると危険な理由と対策など4つのアンチパターンとして紹介しようと思います。 1. Join Lover: データをjoinする 目的 RDBではよくあるテーブル同士を結合してデータを取り出すJoin。 firestoreでjoinを用いたいケースというのは特定のドキュメントのデータだけでは表示する要素が足りないので別のドキュメントから取得してなんとかするみたいな感じになると思います。 しかし、firestoreのプロもおっしゃってますが、firestoreへのjoin追加は望みが薄いと思われます。 RDBで重くなってる要因も外部結合や副問い合わせとかガンガン使って重
こんにちは。Komercoの高橋です。 Komercoがリリースされてからもうすぐ3年が経とうとしています。 クックパッドの新規事業「Komerco」ではバックエンドのほぼ全てをFirebaseで運用してします。 新規事業のためエンジニアの数はまだ少ないものの、Firebaseのおかげでエンジニアはサービス開発に専念できている状況で、昨年はWeb版のリリースや送料無料イベントもあり、ユーザ数がさらに増加してきています。 これまで多くの機能を開発してきましたが、その中でFirebaseをより有効に使えるよう試行錯誤してきました。 これからFirebaseを使おうか考えている人にも、今現在Firebaseを使っている人にも参考になるよう、Komercoで得た知見を書いていこうと思います。 前後編となっており、前半はFirestoreの設計についてお話しようと思います。 当たり前の機能だけどFi
Thredot はスレッド形式でメモを書けるサービスです。 Google アカウントがあればログインできます。 こういうの Playground ページを用意しているので、気軽に使い心地を試してみてください。 Thredot のコンセプト Thredot はアイデアや情報をメモに書き出すハードルを限界まで下げることを目指しており、そのために様々な工夫をしています。 メモを整理させない 爆速な検索機能 公開範囲を設定できる WYSIWYG エディタを採用 メモを整理させない Thredot では徹底的にメモを整理させない方針を取っています。 僕は「整理するための機能が用意されていると整理をしたくなってしまう」人間です。 でも整理するのって超面倒くさいです。 ( 支離滅裂 ) 結局中途半端に整理しようとして余計にゴチャゴチャになり、最終的にメモを書くこと自体が億劫になってしまいます。 Thre
先日、こちらの記事を拝見したのですが、Firebase卒業の理由1位に 「クラウド破産の恐怖」 が挙げられていました。 Firetoreは並列性の高いデータベースですから、ちゃんと作っていれば100万人同時接続でもびくともしません。しかし逆に言えば、もしプログラムに誤りがあって大量の無駄な読み書きが発生すれば、ものすごい勢いでコストが嵩んでいくことになります。実際私も何度か開発中にコーディングミスをして無限再読み込みをしてしまったことがあります。その時は明らかにアプリの動作速度が低下したのですぐに気付きましたが、この危険については私もそれなりに気になるところではあります。そこで、 予算をオーバーしたらFirestoreを自動で停止する仕組み を作ってみることにしました。 プログラムから予算とコストを管理する プロジェクトの現在のコストや予算の通知を受ける方法については、以下の公式ドキュメン
FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対
Jakarta EE Core Profile and Helidon - Speed, Simplicity, and AI Integration
Manage your database on a spreadsheet-UI and build powerful backend cloud functions, scalably without leaving your browser. Start like no-code, extend with code.
1回のポーリングで9回のAPIを呼び出していたのは、予約一覧、予約詳細、ステータス情報など、画面表示に必要な情報を複数のエンドポイントから取得していたためです。これに加えて、多数の薬局クライアントが同時にポーリングを実行するため、リクエスト数が膨大になっていました。 また、予約データは日々構造が複雑になっていき、検索のためにデータベースのテーブルにインデックスを張っても大きな負荷がかかる状況だったため、より本質的な問題の解決を行う必要がありました。 問題の本質：「無駄な」リクエスト ポーリング方式の根本的な問題は、データに変更があってもなくても、定期的にリクエストが発生するという点にあります。 実際の運用データを分析してみると、興味深い事実が分かりました。予約データに変更が発生する頻度は、ポーリング頻度と比較するとかなり低いのです。つまり、大半のリクエストは「変更なし」という結果を返すだけ
Download Free Trial Available for Mac, Windows, Linux Free 14-day trial No credit card required Import & ExportImport and export collections to CSV and JSON. Download backups of your database and transfer data across projects or to the emulator. Powerful Admin PanelView and edit your data in a table, tree or as JSON. Rename and copy collections and documents, query Firestore from JavaScript. Secur
2020年12月頃にFirestore Data Bundlesという機能がリリースされたもののあまり話題になっていないので調べてみました。知らない人も多いのではないでしょうか？ まず参考にしたblogとドキュメントを👇 に載せておきます。公式blogが利用シーンなども書かれておりわかりやすかったのでおすすめです（英語）。 参考 公式blog Load Data Faster and Lower Your Costs with Firestore Data Bundles! 公式ドキュメント Cloud Firestore data bundles Serve bundled Firestore content from a CDN Firestore Data Bundlesとは Firestoreでは、ユーザー全員が同じデータを読み取る場合でもそれぞれのユーザー（デバイス）ごとに読み
カウシェ Tech Blog の Firestore → Cloud SpannerでDBコスト93%削減！無停止でやり切った 1 年間の全記録 という記事が公開されました。 ある程度利用量が増えたら Spanner よりも Firestore の方が高くなるというのは Firestore の前身である Datastore 含め使ったことがあると経験するものですが、データベース移行は大変なので移行できていないユーザは多いでしょう。 無停止での Firestore から Spanner への移行という大変な仕事をやり切ったことは素晴らしいことですね。 ところで、この記事への反応を見ていると特定のポストの引用はしませんが Firestore から Spanner に移行したことで安くなることそのものへの驚きの反応をいくつか観測しました。 実際には Firestore のように Google C
何を作ったか エディタやシンタックスハイライトのテーマは星の数ほどあり、自分が本当に好きなものが何かを答えることは難しいと思っています。そこで、２つのテーマを並べどちらが好きかに回答し続けることで、どのテーマが一番好きかを調べられる syntax highlight battle というサービスを作りました。 FYI: https://syntax-highlight-battle.ojisan.dev/ 元々、最強の syntax highlight を知りたくてバトルするサイトを作った話 というものを作っていたのですが、これは自分がどのテーマを使うか悩んだときに知人にとったアンケートサイトとして作っており、そのときに「自分が選んだ一番気に入っているテーマを知りたい」という声を頂いていたことを思い出したので、作りました。 自分にあうテーマを見つけたい人は是非とも使ってみてください。 改善
※この投稿は米国時間 2025 年 4 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。 このたび Google Cloud Next にて、Google Cloud が一から開発した MongoDB 互換の Firestore を発表しました。この新しい Firestore は、要求の厳しいドキュメント データベース ワークロードに対応するための新たな選択肢を開発者に提供します。 MongoDB との互換性は、60 万人を超えるアクティブな開発者からなる Firestore の既存コミュニティから強く求められていた機能です。今回のリリースにより、Firestore の開発者は、MongoDB の API ポータビリティと Firestore の差別化されたサーバーレス サービスを活用して、強整合性を持つマルチリージョン レプリケーション、実質的に無制限のス
概要と投稿の背景 本投稿では、Firestore の DB 設計の基礎についてまとめます。 私は普段、都内の企業で Flutter エンジニアとして勤務しています。最近は Python/Django のバックエンド API や、Nuxt.js/Vue.js による Web フロントエンドのタスクにも取り組むことがあるのですが、業務レベルで Firestore を使いこなすような機会はありません。 ですが、趣味や個人で使用する範囲のアプリケーションを開発する際には、DB としての Firestore の便利さ・手軽さ・それでいて高機能な面に魅力を感じており、最近では NoSQL データベースや Firestore の特徴をうまく捉え、メリットを活かしながら、いろいろな規模のサービスを Firestore を用いて実現している例もかなりあるようです。 これから行おうとしている個人開発でも、Fi
Get ready for a new faster web experience with Firebase. For the longest time you all have asked us to optimize the size of our JavaScript libraries, and we’ve done just that. We’ve released brand new beta libraries that are significantly smaller in size. Some are even up to 80% smaller! We’ve managed to reduce the size all without removing any features from the previous version too! How did we do
Firestore の JavaScript SDK では、withConverter() を使うと任意のコレクションに型をつけたり自動でデータをデコード/エンコードしたりできますが、コレクションの親子関係の情報は持たないので、SubCollection や Parent を参照するときは毎回手動で withConverter を呼び出さなければなりません。 また、Firestore のセキュリティルールで書き込み時に型チェックをするには手動でルールを記述する必要があり、構文も複雑になりやすいので、できれば TypeScript の型情報から自動でルールを生成したいところです。 Fireschema を使うと、スキーマを宣言的に記述するだけで、親子関係を考慮したデータの型付け、デコード、セキュリティルールの生成などを自動で行うことができます。 Fireschema の機能 Firestor
Firestoreとは Google社が提供するNoSQL型のデータベースです。 特徴として、リアルタイムのデータを受信できる、つまりDB側のデータが変更されるとすぐに、クライアント側に反映される仕組みを提供しています。 FirestoreはNoSQLの1つ NoSQLとはざっくり言えば、RDB以外のデータベース製品です。FirestoreもNoSQLの1つです。Firestoreのデータ構造は、個人的な印象でいえば階層化されているKVSです。 KVSとは KVS(Key-Value Store)とは、JavaでいうMap、Pythonでいう辞書、PHPでいう連想配列にあたるデータ構造です。キーとそれに紐づけられたデータを管理します。 KVSは一般的に逆引きに弱いです。逆引きとは、条件を満たすデータを取得することです。例えば、ユーザIDがキーで名前と電話番号が関連付けられたデータのとき、名
Today at Google Cloud Next, we’re thrilled to announce Firestore with MongoDB compatibility, built from the ground up by Google Cloud. It provides developers with an additional choice for their demanding document database workloads. MongoDB compatibility has been a highly-requested capability from Firestore’s existing community of over 600,000 active developers. With this launch, Firestore develop
tl;dr Firestore は NoSQL のサーバーレスデータベース。 新規開発ならネイティブモードを選択する。 ドキュメント指向のデータモデルを採用していて、コレクション、ドキュメントの階層構造で構成される。 サブコレクションを使うと効率よくクエリができる。 直近のアップデートで、より使いやすくなった。 はじめに みなさん、こんにちは。Google Cloud パートナーエンジニアの Sho です。 この記事は Google Cloud Japan Advent Calendar 2022（今から始める Google Cloud ） の 12/11 の記事です。本記事では、Firestore を取り上げてご紹介させていただきます。 Cloud Spanner や AlloyDB など特徴的なデータベースラインナップを持つ Google Cloud ですが、その中でも NoSQL デ
firestore の SDK に withConverter というメソッドがあるのですが、その宣伝です。 型が欲しいってどういうこと？ たとえば firestore 上のあるドキュメントが name と age というフィールドを持っているとして、それをクライアントが取得したときそのデータに name と age が存在する保証はあるのでしょうか。 db.collection("user") .withConverter(converter) .get() .then(result => { const data = result.docs.map(d => ({ // 本当にnameがある？ name: d.data().name, // 本当にageがある？ age: d.data().age, })) setState(data) }) d.data() はクライアントバリデーシ
モバイル向けNoSQL「Firestore」で件数を数える「count()関数」、期限付きデータ「Time To Live」など新機能。Firebase Summit 2022 Googleは10月18日に米ニューヨークでモバイル向けのバックエンドサービスであるFirebaseにフォーカスしたイベント「Firebase Summit 2022」を開催し、モバイル向けのNoSQLデータベースFirebaseの新機能として、件数を数える「count()」関数や期限が来たら自動的にデータが消去される「Time To Live」などを発表しました。 クエリ結果の件数を返してくれるcount()関数 これまでFirebaseでクエリの結果何件のデータがマッチしたのかを数えるには、プログラマが検索処理の後になんらかの手法で件数を数える処理を記述する必要がありました。 件数を数えることは比較的ニーズの高
muuというバンドメンバー募集サービスを作ったので、使用したライブラリや所感をまとめました。 機能概要 ユーザーページ 活動拠点や楽器、ジャンルなど、基本的な情報をまとめたユーザーページを作成できます。 バンドページ 各ユーザーはバンドを作成して、そのメンバーになることができます。 バンドはユーザーを招待して、メンバーとして紐付けることができます。 活動実績のタイムライン これまで投稿した動画や楽曲などをタイムライン形式で表示できます。YouTube や Spotify、SoundCloud などは埋め込みプレーヤーに対応しており、再生数やいいねの数なども取得して表示します。 実績は個人またはバンドのいずれか紐付きます。バンドに追加された実績はメンバーの個人ページでも共有されます。 募集 メン募サイトなので、当然「バンドメンバー募集」と「バンドに加入希望」の 2 種類の募集を掲載できます。
このブログはクラメソの方がこういうの書いていたので試しに書いてみた感じです。 AWS DevDay Japan 2022 に「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 」というタイトルで登壇しました #AWSDevDay | DevelopersIO 資料 speakerdeck.com 発表理由とか AWSのDevDayはCFPを募集していることから応募した結果、無事に採択されて昨年に引き続きセッションをする機会をいただきました。実は2個出したんだけどもう一方はダメでした。 FirebaseのCloud FirestoreをやめてAWS上で構築したAPIへ移行するという話なんですが実は以前にも検討段階でこのブログで書いた内容です。今回はタイミング的に実際に移行した後ということで前回のブログの内容をアップデートするような内容となっています。 以前のブ
NTT Tech Conference 2022（2022年3月23日開催） 「音声系サービスにおける サーバーレスアーキテクチャの 活用について」 (講演者：西谷 智広[NTTコミュニケーションズ株式会社])の講演スライドです。 GCPのサーバーレスアーキテクチャを使ってNTTコミュニケーシ…
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
この記事のあとに、Elastic Searchを交えた新たな記事を書きました。 AlgoliaからTypeSenseへ切り替えは可能か？#FireStoreを使ってシステムを構築すると、検索機能の貧弱さに頭を抱えることになります。mySQLなどにある「Like検索」は前方一致で行うことは可能ですが、部分一致による検索はできません。 FireStoreの公式サイトでは、全文検索を実装するには外部のデータベースを使用するように案内しています。2021年7月時点では、外部のデータベースとして AlgoliaElastic SearchTypeSenseの3種類が案内されています。現在のNipoではAlgoliaを使って全文検索を実装していますが、実はAlgolia、小規模なプロジェクトでも結構高額になる料金体系のため予算に限りのあるプロダクトでは実装するのが非常に厳しいです。 特に料金形態が変更
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
はじめに はじめまして！！！ 結.JAPAN でみんなで共同編集できる旅行計画アプリnicody のiOSアプリとWebアプリの開発を行なっている、にーの（@n_shhhin）といいます！ 元々、nicodyのiOSアプリの方をメインで開発してたのですが、最近になってWeb周りも担当することになり、初Reactサービス開発ということもあり苦戦しつつ勉強しながら開発しているところです...！👨💻 そんな中、最近 「既存ReactサービスをOGP対応する」 という初心者にはなかなか重めの要件が降ってきて、Web周りは右も左もわからない状態だったのでかなーーーり苦戦しました...！！！ そこで本記事では、今後自分みたいなWeb見習いｴﾝｼﾞﾆｬｰがOGP対応を苦しまずにサクッと実装できるように、OGPを動的に変える方法をつまづいたポイントなどを含め解説してみたいと思います。 この手のOGP
(これはこの記事からの転載です) FireStoreのイベントは、Eventarcを用いることで他のサービス、例えばCloud Runなどをトリガーできます。 今回、Eventarcを用いてFireStoreのイベントをトリガーとしてCloud Runを呼び出してみることにします。 EventarcはAuditとPub/Subの両方から流し込むことができます。PubSubはCloud PubSubとして他のいろいろなところから流し込むことができ、AuditはFireStoreのイベント以外にもGoogle Cloudで起きるほぼすべてのAPI呼び出しをイベントとして流し込めます。 1. 取得したいイベントの監査ログを有効化する 最初にEventarcを有効化する監査ログの種類を指定し、有効化します。 IAM権限管理 -> 監査ログ で、 "Firestore/Datastore API"
Fjelltoppjakten now has over 16 000 users, and a highly requested feature has been to search for users by name. We have a users collection in Firestore with the following data structure: users/$userId { name: String imgUrl: String, location: String }We wanted to implement a search field in the app so that users can find their friends, and they should be able to search for partial names and have so
ウェブ版 CloudFirestoreのクエリ備忘録 日本語版公式ドキュメントに載っていないものがいくつかあったので、まとめてみた。 ※コレクショングループについては書いていません。 更新情報 2023/5/13 ORクエリについて追記しました 2022/2/10 日本語版公式ドキュメントに追記されていました。 Firebase SDK v9の記法を追記しました。 // コレクション users: { // ドキュメント "000": { // フィールド address: { prefecture: "沖縄", region: "沖縄", }, age: 20, createdAt: 2020年11月10日 15:00:00 UTC+9, friends: ["003"], userName: "山田太郎", }, "001": { address: { prefecture: "北海道
本稿ではFirestoreの概要、NoSQLデータベースの構造、Firestoreの初期設定、Reactの初期設定、書き込み、react-firebase-hooks（useCollection、useDocument）を使った読み込み方法（実装方法）まで丁寧に解説しています。書き込みはweb Version 8での記法と、2021年8月に正式リリースされたより新しいweb Version 9での記法を両方解説しています。 FirestoreとはFirestoreとはFirebase（Google Cloud Platformとほぼ同義）内で利用できるのNoSQLのデータベースで、最大の特徴はReact等フロントエンドから直接DBを操作できる点です。バックエンドを記述する必要がなく、フロントエンド側でFirebaseライブラリーを使ってDBへの書き込み・読み込みが簡単にできます（もちろんバ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く