FirebaseがZapierを統合: リアルタイムインフラに複数のアプリケーション間通信が加わる

次の記事

オバマケアの中小企業向けオンライン登録システム、提供時期遅延

アプリケーションを管理するためのリアルタイムのバックエンドサービスを提供しているFirebase企業プロファイル)に、既存のそのほかのサービス、SendMail、Twitter、Twilioなどなどと接続するためのサービスZapierとの統合が加わった 。これからは、Firebaseのライブラリを使って共有的/コラボレーション的なアプリケーションを開発するデベロッパが、そのアプリケーションから既存のさまざまなアプリケーション/サービスに接続でき、しかもそのためのバックエンドサーバの管理はいっさい不要だ。

Firebaseを利用するユーザは、これまで相当量の作業を要した他のアプリケーションとの統合を、比較的容易に行えるようになる。FirebaseのCEOで協同ファウンダのJames Tamplinは曰く、“この統合により、自分でサーバサイドのコードを書く必要がなくなる”。すなわち、Firebaseのサービスを介してほかのアプリケーションと接続するためには、わずか5行のコードを書くだけだ。それにより、メンテナンスなどの面倒な管理業務もFirebase側でやってくれる。というか、Firebaseに統合されたZapierがやってくれるのだ。

たとえばFirebase~Zapier経由でSendGridというサービスに接続すると、メールとその通知を送れるようになる:

Firebase___Zapier_to_Power_Your_App_s_Integrations_·_Service_Updates_-_Zapier

以下は、GTalk(IM)、Twilio(SMS)、MailChimp(メルマガなど)の例だ:

Connect_Firebase_to_120__API_services_with_Zapier

これからのデベロッパはますます、JavaScriptのコードだけを書き、その際Angularのようなフレームワークを使用し、そしてFirebaseのようなプラットホームを統合してバックエンドの管理を任せるようになる。バックエンドの面倒から解放されてアプリケーションの本体だけに集中できる次世代型フロントエンドデベロッパの増加に伴い、Firebaseはますます利用価値を増す。数あるバックエンドサービスの中でもFirebaseの特長は、データストレージに関してもFirebaseのAPIを利用できることだ。しかもそのリアルタイム機能は、ほかのバックエンドサービスプロバイダにはないものだ、とTamplinは主張する。

彼によると、Firebaseのサービスはストレージを(リアルタイムの)syncのパラダイムへ抽象化している。つまりアプリケーションに新たなデータが加わると、エンドユーザはブラウザをリフレッシュしなくてもそれを見る。しかもFirebaseではデベロッパが、シンクのためのバックエンドのタスク…データベース、サーバコードなど…を実装/管理する必要がなく、アプリケーションのロジックのみに集中できる。

APIエヴァンジェリストのKin Laneによると、Firebaseにはこの自動sync機能があるために、ユーザ1名から100万名へのスケールアップが、1行もコードを書き換えずに可能になる:

FirebaseのAPIは最初から、パフォーマンスとスケールを視野に入れて作られている。デベロッパがクライアントレベルでシンクしたいデータを指定すると、Firebaseはアップデートすべき最小のデータ集合を計算して、全ユーザに対するシンクを行う。さらにFirebaseのAPIはすべて、シンクされるデータのサイズに合わせて線形にスケールし、分散クラウド環境でも良好に共有されるよう設計されている。しかもすべてのスケーリングと関連オペレーションを、ユーザの介入なくFirebase自身が行う。したがってあなたのFirebaseアプリケーションは最初のユーザから最初の100万のユーザまで自動的にスケールし、そのためにコードを書き換える必要はない。

ユーザがZapierのサービスを介して接続するアプリケーションの認証も、シンクの機能を利用しながらFirebaseがすべて処理する。そのため、複数のアプリケーション間の通信を実装するという面倒なプログラミングの課題から、アプリケーションデベロッパは解放されるのだ。

(画像提供: Flickr上のColin Dunn, クリエイティブコモンズのライセンスによる。)

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))