LoginSignup
691
618

More than 5 years have passed since last update.

@gonta616

フロントエンジニアが今話題のFirebaseについて語りたい

Last updated at Posted at 2016-10-06

最初に

最近、Firebaseについての記事をよく見ます。
稚拙ながらもFirebaseについて注目している一人として語りたい。
知識不足(特に後述の歴史の認識)のため、駄文乱文あると思います。ご指摘いただけると幸いです。

Firebaseとは

mBaas(Mobile Background as a Service)の一つで、Googleの買収で一気に知名度が上がりました。
今までも、十分使えるものでしたが、2016年のGoogle I/Oの発表で統合プラットフォームとしての風格がムンムン漂ってきました。
また、Parse終了の知らせがでるやいなや無料プラン(SPARK)の改変、push notificationの無料化には心が震えました。商売が上手いですね。

スクリーンショット 2016-10-06 9.08.36.png


あと、日本語ドキュメントが豊富なのもいいですね!　さすがGoogle先生。

Firebaseでできること（抜粋）

  • リアルタイムデータベース
  • Firebase Analytics
  • Auth
  • A/Bテスト
  • Hosting
  • ストレージ
  • push notification(Mobile)

Parse終了が通達された今、mBaasとして使うのが一番多い選択肢だと思います。
ただし、Hostingがあり、webアプリを簡単にデプロイすることができます。
高機能でサーバーレスアーキテクチャなFirebaseは、昨今できることが多くなったフロントエンドと相性が良いです。

自分視点ですが、

  • Webの歴史から、なぜフロントエンドエンジニアが注目すべきか。
  • Firebaseに合う構成

を書きたいとおもいます。

Webの歴史

1.動的DOMの時代

CGI(PHPやPerl)ユーザーの要求に応じてページ単位でHTMLを返していた時代。サーバーサイドレンダリングが全て。
このころの経験はないのですが、インターネット黎明期でmixiやライブドアなどが活躍してたのを、覚えてます。

(状況)
サーバーサイド　 >>> HTMLコーダー(コーダーであってるのかな？)

2.ajax + jQuery全盛期

webが一気に活気づきます。
2008年位でしょうか？ajax + jQueryがgoogle mapの登場で認知されました。
それまで静的だったページに、ページを遷移することなく、データをGETし、さらにサクッとDOMを書き換えることができます。webページに動きが出ます。
html + css + javascriptが使えるhtml コーダーの需要が増加します。

(状況)
所謂、LAMP開発者とHTMLコーダーが組んで仕事していた時代。
サーバーサイド >= HTMLコーダー

3.Ruby on RailsのMVCフレームワーク(サーバーサイド)の時代へ

web開発が大きく変換を迎えます。Ruby on Rails(ruby)やSymfony(php)などのフレームワーク(道具箱)で早く、そして簡単に、webが作れるようになります。webに設計が持ち込まれます。
MVCモデルの採用で大規模複雑化したアプリケーションの構築が可能となります。
それに伴い、様々な優秀なサービスが誕生し、成功します。これによりユーザーは良いweb体験を手に入れます。

(状況)
サーバーサイド(Rails エンジニア) >>>>>>>超えられない壁>>>>> HTMLコーダー
※バズワードになっていたのが「フルスタックエンジニア」。フレームワークでアプリを構築しつつ、サーバーの選定、jQuery + ajaxをいじれるスキルセットを持つ人だと認識しています。

4.フロントエンドフレームワークの台頭

技術の進化とは恐ろしいものです。スマートフォンの台頭により、ユーザーはよりリッチでストレスレスな体験をwebに求めます。しかし、今までのajax + jQueryでは複雑化、大規模化したwebを扱うのは難しくなっていました。

そんな要望から、フロントに設計(MVC)を持ってきたフレームワークが誕生します。(解決のアプローチとしてSPAがあったりする。）

  • 先駆けとなった、Backbone.js、
  • 高機能なのにモジュール化がしっかりしてて扱いやすいgoogle社が開発するAngular.js、
  • 仮想DOMやデータフローでパラダイムを感じさせた、Facebookが開発するReact.js

など人気のフレームワークが誕生し戦国時代となります。

また、開発規模が大きくなるにつれ、module管理、タスクランナー、コンパイラが必要となってきて、フロントエンドでできることと、複雑さが指数関数ばりに年々増加します。

この背景から、フロントエンドエンジニアという概念が生まれます。

(状況)
サーバーサイドエンジニア >= フロントエンドエンジニア
開発構成によりけりだと思いますが、フロントエンドエンジニアがサーバーサイドエンジニアに追いついた。状況だと思ってます。というより、複雑化、多様化により分業化が進んできてるのかな。。。

とはいえ、JSエンジニアの地位がグッとあがった数年だと思ってます。

構成の変更

フロントエンドでできることが多くなったため、アプリケーション構成も変わりました。

フロントエンドフレームワーク台頭まで
フロント：HTML + CSS(bootstrap?) + jQuery + ajax
サーバー： Ruby on Rails, Symphony (サーバーサイドレンダリング)　
(大きいサーバーサイド、小さいクライアントサイド)

から

フロントエンドフレームワーク台頭後
フロント：React, Angular, Backbone
サーバー：express(node.js) , Ruby on Rails, Symphony (JSON API)
(小さいサーバーサイド、大きいクライアントサイド)

のような構成も採用されるようになりました。
また、サーバーをJSON APIにすることでスマホアプリの構成も同じにすることができ、この形を採用されるプロジェクトが増えたと思います。
この結果、雑にいうと、フロントはjsonでデータをもらえれば、リッチなアプリケーションを構築できるようになりました。

フロントエンドいつまでたっても独立できない問題

フレームワークの登場でフロントエンドで出来る事が多くなりました。(ブラウザの強化や、pcのスペックの向上やら総合的な要因ですが、今は置きます)

しかし、フロントエンド単体では殆どのアプリが完結することができません。

何故なら、dbとやり取りするためにはサーバーサイドプログラムが必要だからです。

少し前なら、しゃーねーサーバーサイド書くかぁ。だったのが学習コストの増加でJSばっかやってると頭の切り替えも、ンギギギと悲鳴をあげます。
(余談ですが、node.jsがウケたのは言語的縛りもあると思ってます)

自分が考える。楽な構成

  • フロント : React, Angular… <- フロントの領域(得意)
  • サーバー : Symfony(php), express(node.js) <- JSON API作らんとあかん(苦手)
  • インフラ : Heroku … <- Paasに任せる。(でも苦手)

普段はチームでやってる為、分業化されてますが、１人で何かやりたいなぁという時や、お金を掛けられない要望がある時が辛いです。
どうしてもサーバー、インフラの所で工数がかかります。
そんな中、サーバーレスでこの問題を解決できるかもってなったのがFirebaseです。

※ 少人数の時みたいに書いてますが、firebaseはスケールし易いようになってて、普通にデプロイ先として使えます。
https://firebase.google.com/pricing/

Firebaseに合う構成

前置きがかなり長くなりました。
Firebaseは、
フロントエンドフレームワークを利用し、
JSON APIを返すサーバーサイドを構築することなく、
リッチなwebアプリケーションを作るのに適していると考えています。

・フロント : React, Angular… <- フロントの領域(得意)
・サーバー + インフラ : Firebase (サーバレスでJSON API。Firebaseに任せる)

個人的にはReduxとの相性が抜群に良いためReact + Firebaseの組み合わせを押したいのですが、
Angular + Firebaseは同じGoogle 製のため連携がいいのかもしれない。と思ってます。(未検証)

Firebaseは夢を見るのか？

一概に言えないと思います。
DB的縛りがあります。FirebaseはNoSQLを採用しているので、リレーションができません。
クライアントからなのでmongoのmethodを発行することもできません。

すみません。嘘いいました。SQLのWHEREにあたるのは用意されています。
https://firebase.googleblog.com/2013/10/queries-part-1-common-sql-queries.html#byemail

JOINはできたかわかりません。
こうなると論点はRDB vs NoSQL ですねw

例えば、顧客情報や商品情報などを扱うのは今まで通りRDBを得意とするサーバサイドフレームワークを使うべきです。CMSを構築するならWordPressなど特化したものもあります。
また、リアルタイムデータベースも若干割高といった印象を受けます。

データ構造がシンプルで良いユーザビリティを提供したい場合は十分に選択肢にいれてよいと考えています。

また、SPARKが非常に強力で初期であれば無料でスタートできます。

まとめ

  • Firebaseが良いのはフロントエンドエンジニアのできることが増えてるから
  • フロントエンドフレームワーク + Firebaseのサーバーレス構成が魅力的
  • 得意不得意があるから見極めること

流行ってほしいなぁ。。。

参考

https://firebase.google.com/docs/
http://qiita.com/kohashi/items/43ea22f61ade45972881
http://jp.techcrunch.com/2016/05/20/20160518google-turns-firebase-into-its-unified-platform-for-mobile-developers/

691
618
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
691
618