「Firebase」タグの記事が3件件あります

🛜アプリ開発を加速する次世代クラウドサービス​

▶️はじめに​

業務でSQLを使用してデータ操作をしているうちに、『NoSQL』とはどういったものか？

どうやってデータを操作するのかとうい好奇心が湧きました。

そこで手軽に『NoSQL』を試せる環境がないかと調べていると、

今回の題目である【Firebase】にたどり着きました。

調べてみると、Googleが提供する「Firebase（ファイアベース）」は、近年のアプリ開発では、

スピードと柔軟性が求められる中、モバイル・Web開発において注目を集める存在のようです。

本記事では、予備知識ゼロの筆者がFirebaseの基本的な機能やメリットに加え、

他のクラウドサービス（AWSやAzure）との違いも含め、自分なりに理解した内容を解説します。

また、弊社箕浦のTechブログでは実際にFirebaseを設定している記事が掲載されていますので、

ご興味のある方は是非ご参照ください。

https://techblog.dearsystem.jp/blog/2024-04-05-01

|

▶️Firebaseの概要​

Firebaseは、Googleが提供するクラウドベースのアプリ開発プラットフォームです。

サーバーの構築や運用を意識せずに、リアルタイム通信・ユーザー認証・データ保存・通知配信などの

機能をアプリに簡単に組み込める、**BaaS（Backend as a Service）**の代表格です。

開発者はFirebaseを使うことで、サーバーレス環境でバックエンドの構築・運用が可能 となり、

フロントエンドやUI開発に集中しやすくなります。

リアルタイムデータベース、認証、クラウドストレージ、分析、通知など、

アプリに必要な多くの機能をワンストップで提供しています。

元々は2011年に独立した企業としてスタートし、2014年にGoogleに買収されて以降、急速に進化を遂げています。

|

▶️Firebaseで実現できること／得意なこと​

1. リアルタイムデータの同期​

Firebase Realtime Database や Cloud Firestore により、複数端末間でデータをリアルタイムに同期。

チャットアプリや出欠管理、ライブ更新系のアプリに最適。

2. 認証機能の実装​

Googleアカウント、メール認証、電話番号など複数の方式を数行のコードで導入可能（Firebase Authentication）。

3. 通知の配信​

Firebase Cloud Messaging（FCM）で、モバイルやブラウザへのプッシュ通知を簡単に実装。

4. クラウドストレージ​

Firebase Storage で、画像やドキュメントなどのファイルをクラウドに安全に保存・共有可能。

5. ユーザー行動の分析​

Firebase Analytics により、ユーザーの操作や行動履歴を可視化し、改善施策に活用。

|

▶️Firebaseのメリットとデメリット​

メリット​

サーバーレスで開発が可能（インフラ管理不要）

リアルタイム通信が得意（双方向の即時同期）

セットアップが簡単（初心者でも扱いやすい）

Googleインフラによる高いスケーラビリティ

Webとモバイル両対応

デメリット​

無料プランには利用制限がある（同時接続数や転送量）

複雑なSQL操作には不向き（NoSQL型）

依存度が高いクラウド設計（オフライン対応が限定的）

データ構造設計次第でコストが予想外に膨らむ可能性

|

▶️Firebaseの課金情報（ 2025年時点）​

Firebaseには無料と有料の主に以下の2プランがあります。

小規模なアプリでかつ、扱うデータ量も少ないならば、無料でも十分使用できます。

Blazeプランの参考料金（USD）

Realtime DB 保存：$5/GB、ダウンロード：$1/GB

Firestore 書込：$0.18/10万件、読込：$0.06/10万件

Storage 保存：$0.026/GB/月、転送：$0.12/GB

※地域・為替によって変動あります。最新の公式サイトで確認を。

|

▶️Firebaseと AWS / Azureの違いは？​

同様の要件で検討対象となるAWSやAzureとは、いったいどういった違いがあるのでしょうか

Firebase、AWS、Azureはそれぞれクラウドベースのサービスですが、目的や設計思想が大きく異なります。

以下にFirebaseとの差異をまとめてみました。

|

▶️Firebaseが向いているケース​

⇒ アジャイル開発・プロトタイプ作成

⇒ リアルタイム性が必要な教育アプリや出欠管理

⇒ サーバー構築の専門知識がない小〜中規模プロジェクト

⇒ AWS/Azureが向いているケース

⇒ 複雑な業務システムや高トラフィックアプリ

⇒ リレーショナルデータベースを多用する場合

⇒ セキュリティやカスタマイズの自由度が求められる場合

|

▶️まとめ​

Firebaseは、スピーディーにアプリ開発を進めたいチームや個人開発者にとって

非常に強力な選択肢となりそうです。

特にリアルタイム性やモバイル/Webの統合開発が必要な場面では、

他のクラウドサービスと比較しても抜群の効率性を発揮すると考えられます。

一方、AWSやAzureはより柔軟で強力なインフラ制御が可能なため、

エンタープライズ向けや大規模サービスに適していると考えられます。

★ Firebaseは**「すぐ作れる」「すぐ動く」**を最重視するプロジェクト向き。

★ AWS/Azureは**「自由に作れる」「複雑なシステムに対応できる」**のが強み。

|

▶️あとがき​

当初の疑問であったはずの『NoSQL』はどこいった？？？

という内容のブログになりましたが、実はFirebaseを使用して、簡単な『出欠確認アプリ』を

試作しているところです。

運よく完成となった暁には、今回触れることができなかったFirebaseの実際の設定方法や

『NoSQL』の使用感もあわせて記事にできればと考えております。

（断念したらすみません。。。）

ただ、この『Firebase』には可能性を感じており、「自前のデータベースやシステムを持ちたいけれど、

AWSやAzureみたいな大がかりの物はちょっと・・・」とDX化に二の足を踏む

中小事業者向けのサービスとして、手軽に扱えかつ、開発工数も抑えられる本環境は

最適かとも思いました。

こんにちは。開発 2 部 箕浦です。
現在、関わっている案件でWebプッシュ通知について調べる機会がありましたので
実装の仕方からブラウザ間の挙動の違いを調査した結果を紹介します。
本記事は、後編であるフロントエンド編になります。

今回はフロントエンドはReactで実装します。

Service Worker​

Webプッシュ通知は、ユーザーがウェブサイトを見ている状態だけでなく、他のサイトを見ているときや、別のアプリケーションを動かしているときなどにも通知されてほしいです。
WebアプリケーションはReact(Javascript)でブラウザ上で動作するものなので、基本的にはユーザーがウェブサイトを閲覧していないときは動作しません。
そのため、Webプッシュ通知を受け取ったときの動作は、本体のWebアプリケーションとは別のプロセスで動かしておいて、プッシュ通知の処理を行う仕組みが必要となります。
その役割を担うのがService Workerです。
Service Workerは、プッシュ通知だけでなく、バックグラウンドで何か処理をさせたいときなど用途はいろいろあります。
ただし、ブラウザの種類やバージョンにより、サポート状況や挙動が変わることがありますので事前に動作確認が必要となります。

publicフォルダ配下に以下の service-worker.js ファイルを作成します。 簡単に説明すると、
push イベントに対して、タイトルやメッセージなどを受け取り、 showNotification を使って、デスクトップにプッシュ通知を表示します。
notificationclick イベントに対して、通知がクリックされた際に、指定したURLへ遷移するようにしています。

addEventListener('push', (event) => {
    console.log('[Service Worker] Push Received.');
    console.log(`[Service Worker] Push had this data: "${event}"`);

    if (!(self.Notification && self.Notification.permission === 'granted'))
        return;

    var data = {};
    if (event.data)
        data = event.data.json();

    console.log(data)

    self.clients.matchAll().then(clients => {
        clients.forEach(client => {
            client.postMessage({
                data: data
            });
        });
    });

    var title = data.data['pinpoint.notification.title'];
    var message = data.data['pinpoint.notification.body'];
    var icon = data.data['pinpoint.notification.imageIconUrl'];
    var image = data.data['pinpoint.notification.imageUrl'];
    var options = {
        body: message,
        icon: icon,
        image: image,
        data: data,
    };
    event.waitUntil(self.registration.showNotification(title, options));
});

addEventListener('notificationclick', (event) => {
    event.notification.close();
    event.waitUntil(
        clients.openWindow(event.notification.data.data['pinpoint.url'])
    );
});

React​

React側ではまず、firebase のライブラリをインストールします。

npm install firebase

App.jsに前編でFirebaseコンソールからコピーしたコードスニペットをそのまま貼り付けます。

import { initializeApp } from "firebase/app";
import { getAnalytics } from "firebase/analytics";

const firebaseConfig = {
  apiKey: "APIキー",
  authDomain: "webpush-c7bed.firebaseapp.com",
  databaseURL: "https://webpush-c7bed.firebaseio.com",
  projectId: "webpush-c7bed",
  storageBucket: "webpush-c7bed.appspot.com",
  messagingSenderId: "586895317040",
  appId: "アプリ ID",
  measurementId: "G-SPL1GEMWDJ"
};

const app = initializeApp(firebaseConfig);
const analytics = getAnalytics(app);

同じく、以下のコードを追記します。
「サーバーキー」には、前編でFirebaseコンソールからコピーしたサーバーキーを設定します。
今回はサーバーキーや上記の設定は、ソースコードにハードコーディングしていますが、本番環境で使用する場合は、外から読み込むなどの仕組みが必要です。

import { getMessaging, getToken, isSupported } from "firebase/messaging";
const messaging = getMessaging(app);

const vapidKey = "サーバーキー"
var registeredServiceWorker;
navigator.serviceWorker.register('/service-worker.js').then((reg) => registeredServiceWorker = reg)

function App() {

  useEffect(() => {

    function requestPermission() {
      isSupported().then((isSupport) => {
        if (!isSupport) {
          console.log('Messaging is not support.');
          return
        }
      
        console.log('Requesting permission...');
        Notification.requestPermission().then((permission) => {
          if (permission === 'granted') {
            console.log('Notification permission granted.');
            getTokenRequest()
          }
        })
      })
    }
    
    async function getTokenRequest() {
      // Add the public key generated from the console here.
      getToken(messaging, {
        vapidKey: vapidKey,
        serviceWorkerRegistration: registeredServiceWorker
      })
        .then((currentToken) => {
          if (currentToken) {
            // Send the token to your server and update the UI if necessary
            // ...
            console.log(`token: ${currentToken}`);
            // ここで取得したトークンをサーバーへ送信する
          } else {
            // Show permission request UI
            console.log('No registration token available. Request permission to generate one.');
            // ...
          }
        }).catch((err) => {
          console.log('An error occurred while retrieving token. ', err);
          // ...
        });
    }
    requestPermission();
  }, []);

  return (
    <div className="App">
      <div>
        ・・・
      </div>
    </div>
  );
}

ここまでで実装は完了です。

プッシュ通知の送信​

フロントエンドをローカルで起動します。

npm run start

ブラウザが起動すると、画面上部にプッシュ通知を許可もしくはブロックするがポップアップで表示されます。
ここで許可を選択しておきます。
ブロックを選択すると、プッシュ通知が届かなくなります。

すると、トークンが払い出されます。 今回はわかりやすいようにトークンをデバッグコンソールに出力しています。

本来であれば、このトークンをサーバーへ何らかの方法で送り、サーバー側でユーザーと紐づけて管理しておきます。
今回はサーバーは省略しているので、このトークンをコピペすることにします。

今回はプッシュ通知の送信は簡単に確認するため、Amazon Pinpointのコンソール画面から送信します。
デバイストークンには先ほどコピーしたトークン
プッシュ通知サービスには「FCM」
を入力し、メッセージの内容を入れて、プッシュ通知を送信します。

送信を行うと、デスクトップの右下に無事プッシュ通知が表示されました！！

ブラウザによる挙動​

ここからは、ブラウザによるプッシュ通知の挙動を確認していきます。
今回はChrome、Edge、FireFoxの３種類で確認することにします。

デフォルトの状態でのプッシュ通知の表示​

まずはデフォルトの状態でのプッシュ通知の表示は、

Chromeの場合

Edgeの場合

Firefoxの場合

こちらは、同じ結果となりました。

requireInteractionを有効​

ユーザーがクリックするか閉じるかするまで、通知が自動的に閉じずに残る設定である requireInteraction を有効にした場合、

Chromeの場合

Edgeの場合

Firefoxの場合

こちらは、Edgeの場合は「閉じる」ボタンが表示されず、25秒ほどで通知の表示が消えました。 Edgeの場合、requireInteractionの設定だけではだめなようです。

プッシュ通知を閉じずに、連続して何回か送信した場合​

プッシュ通知の「閉じる」ボタンを押さずに、連続して何回か送信した場合の動作を見てみます。

Chromeの場合

Edgeの場合

Firefoxの場合

ChromeとFirefoxでは、連続して送ると、3つまではデスクトップに表示されますが、それ以降は、 デスクトップに表示せず、通知管理に溜まっていく動作となっていました。
その状態で閉じるボタンで通知を閉じると通知管理に溜まっていたものが、 順番に表示されます。
Edgeでは、通知管理には溜まっていきますが、どれだけ送っても、デスクトップには1つまでの表示となっています。

ブラウザを起動していない状態でのプッシュ通知​

ChromeとFirefoxでは、即時に通知表示されず、ブラウザを開いて、20秒ほど待っていると、 それまで溜まっていたものが一度に通知されてくる動作となっています。
それに対し、Edgeでは、ブラウザを起動していない状態でも、プッシュ通知が表示されました。

ブラウザによって、プッシュ通知のサポート状況や、実装は以後のバージョンアップで動作は変わる可能性がありますが、 現時点ではこのような差異がありました。
他にもいろいろな設定がありますので、今後も色々触ってみようと思います。

こんにちは。開発 2 部 箕浦です。
現在、関わっている案件でWebプッシュ通知について調べる機会がありましたので
実装の仕方からブラウザ間の挙動の違いを調査した結果を紹介します。
本記事は、前編であるバックエンド設定編になります。

Webプッシュ通知とは​

Webプッシュ通知とは、ウェブサイトからユーザーに対して通知を送信する仕組みです。
画像のようにウェブサイトにアクセスした際、通知の許可を求めるポップアップで「許可」を選択し、
デスクトップ右下にポップアップされるあれのことです。
ブラウザがサポートしている場合、ユーザーはウェブサイトから通知を受け取ることができます。

iOS16.4から既にサポートされており、iPhoneでもWebプッシュを受けれるようになっています。

Webプッシュ通知を実装するには、バックエンド側の実装が必要になるのですが、Webプッシュといってもいろいろな方法があり、サービスも複数あります。

今回は、簡単に、Firebase Cloud Messaging と Amazon Pinpoint というサービスを組み合わせて実装します。 Firebase Cloud Messaging だけでもWebプッシュは可能ですが、管理コンソール画面からプッシュ送信することを考え、Amazon Pinpointの管理コンソールからの方が送りやすいため、Amazon Pinpointを組み合わせました。

さらに、今回は詳しく取り上げませんが、Amazon Pinpointを利用すると、ある特定のユーザグループのみWebプッシュを送信するという使い方ができますので、特定の地域に住む人のみとか、特定の年齢層の人のみにWebプッシュを送信するといったことも可能です。

Firebase​

まずは、Firebase にプロジェクトを作成します。 Firebase を利用するにはGoogleアカウントが必要になります。

続いて、上記で作成したプロジェクトにウェブアプリを追加します。 今回は下のようなアプリを作成しました。

下の方の「SDKの設定と構成」の欄にnpm、CDN、Configでそれぞれ実装するときのコードスニペットが表示されていますので、フロント側にこれを組み込みます。
今回はReactで実装しますので、npmを選択します。

また、「Cloud Messaging」タブでAPIが有効になっていることを確認し、 「サーバーキー」もメモっておきます。

Firebase Cloud Messagingの設定は以上です。

Amazon Pinpoint​

つづいて、Amazon Pinpointの管理コンソールに入り、
こちらもプロジェクトを適当に作成し、 プッシュ通知の設定にてFirebase Cloud Messaging (FCM)の キー認証情報のAPIキーの欄に先ほどメモした「サーバーキー」を設定します。

Amazon Pinpointの設定は以上です。簡単ですね。

次回の記事では、フロント側の実装方法について解説し、実際の挙動を確認します。

お楽しみに！