こんにちは。プレイドの藤川(@atsushiss15)です。 
プレイドには学生時代よりインターンとして参加しており、今年の４月に新卒社員として正式に入社しました。現在に至るまで弊社の提供するKARTEの機能開発を担当しています。
今回はVue.jsを利用したコンポーネント指向のUI開発において、私たちが実際に遭遇した問題とその解決策として導入したStoreパターンについてご紹介したいと思います。 
Vue.jsというフレームワークが題材にはなりますが、Storeパターンの考え方自体は他のフレームワークを使った開発にも転用できると思うので、ぜひ読んでみていただければと思います。
<h1>目次</h1>
<ul>
<li>Vue.jsとは？</li>
<li>アプリケーションの大規模化に伴って生じた問題</li>
<li>解決策としてのStoreパターン</li>
<li>サンプルコード他</li>
<li>Storeパターンに移行した感想</li>
<li>最後に</li>
</ul>
<h1>Vue.jsとは？</h1>
<a href="http://jp.vuejs.org/">Vue.js</a>を一言で表現するならば、「シンプルさが売りのMVVMフレームワーク」です。 
他の有名なMVVMフレームワークにはAngularJSやReactなどが挙げられますが、それらに比べてVue.jsはそのシンプルさ故に学習コストが低い上、あらゆる規模のアプリケーションで利用することができる設計になっています。
Vue.jsを知らない方でも、簡単なToDoアプリの実装例を見てみれば大体の使い方が理解できるのではないでしょうか。

<script>
 (function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "https://platform.wantedly.com/visit_buttons/script.js";
 fjs.parentNode.insertBefore(js, fjs);
 }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<script async src="//jsfiddle.net/atsushiss15/kj29sbh1/embed/js,html,result/"></script>
上記のコードは、Vue.jsの公式サイトに掲載されているサンプルのコードを便宜上CoffeeScriptで書き直したものです。
簡単に解説をしてみます。 
id属性を用いてVueインスタンスと仮想DOMの紐付けを行い、<code>v-model</code>でデータの双方向バインディング、<code>{{ }}</code>構文でテキストのレンダリング、<code>v-for</code>でリストのレンダリング、<code>v-on</code>で要素にイベントリスナのアタッチをそれぞれ行っています。
Vue.jsはこの辺りさえ抑えておけば、とりあえずコードを書き始めることができるので便利です。
<h1>アプリケーションの大規模化に伴って生じた問題</h1>
Vue.jsの最も大きな特徴の一つにコンポーネントシステムがあります。 
この仕組みを利用して、アプリケーションのUIをコンポーネントレベルに分割し、組み合わせるように実装することで、コードの再利用性が向上し、ロジックも各コンポーネントの中にカプセル化することができます。
コンポーネントの状態は各コンポーネントがそれぞれ管理し、状態やイベントの共有は<a href="http://jp.vuejs.org/api/#props">props</a>や<a href="http://jp.vuejs.org/api/#vm-dispatch">$broadcast</a>/<a href="http://jp.vuejs.org/api/#vm-broadcast">$dispatch</a>といった仕組みを利用して行います。 
下図はコンポーネント間でのデータやイベントの伝達をイメージしています。propsを用いてデータを子コンポーネントへ明示的に受け渡したり、$broadcastや$dispatchを使って他コンポーネントへイベントの通知を送ることができます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ad51dcdd-703b-4f66-8255-89a89c6bdbcb/----------2016-10-12-19.27.58.png" alt="">
しかし、これらの仕組みを利用すると、アプリケーションの大規模化に伴い状態管理が複雑になってきてしまいます。 
状態が多くのコンポーネントに分散し、更にそれらが相互作用するようになるとpropsや$broadcastを使ったコンポーネント間でのデータやイベント伝達の仕組みが多用され、コンポーネント同士が密結合・複雑化し始めるのです。 
実際にKARTEの開発においても、これらが原因でコード変更の影響範囲が分かりづらく改修が困難になり、コードの重複やサーバーサイドとの無駄な通信などが散見されるようになっていました。
<h1>解決策としてのStoreパターン</h1>
そこで私たちはStoreパターンによってアプリケーションの状態（State）・処理（Actions）・イベントの共有を行うことで、密結合しているコンポーネントの分離、コードの重複や無駄な通信の削減を目指しました。
<h2>私たちがStoreパターンと呼んでいるもの</h2>
Storeパターンは、Storeというグローバルな共有オブジェクトに複数のコンポーネントから使用される共通の状態・処理・イベントを管理させることで、コンポーネント同士を分離する考え方です。
下図のように、ユーザーから何らかの入力を受けたコンポーネントはStoreの共有処理（Shared Actions）を直接Callすることで共有状態（Shared State）を更新します。各コンポーネントはこの共有状態を監視することでそれぞれの表示を変化させます。 
また、Storeには共有のイベントも管理させます。何らかのイベントをトリガにしてコンポーネントごとの処理を行いたいケースなどは、これを利用して各コンポーネントに通知を送信します。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6593975e-2483-4c37-a10a-0c568d0ed4bd/----------2016-10-13-3.02.32.png" alt="">
<h2>「Fluxとは何が違うの？」</h2>
というご指摘が挙がってきそうなので、<a href="https://facebook.github.io/flux/">Fluxアーキテクチャ</a>との差分についても少し触れておきたいと思います。
<a href="http://v1.vuejs.org/guide/application.html#State-Management">Vue.js公式ドキュメント</a>でも言及されていますが、store patternは共有の状態・処理をグローバルなオブジェクトに管理させることでコンポーネント同士が密結合・複雑化してしまうのを防止することを目的としています。
そういった意味で、Fluxはstore patternの考え方をベースに、Event Dispatcherによる一方向（one-way）の状態更新フロー以外は許容しないという制約を加えたアーキテクチャであることが分かります。 
対して、私たちがStoreパターンと呼んでいるものは、Fluxの思想自体は汲み取りつつ柔軟性とシンプルさを担保したものであるといえます。
具体的には、状態更新に関する制約を設けないことで柔軟性を確保し、Event Dispatcher等は介さず直接関数をCallして状態更新を行うことでシンプルさを保つようにしています。そのためTPOに応じてコンポーネントが直接Storeの状態を書き換えることも許容します。
このように私たちがFluxのように、制約によってキレイに整理された（しかし少し大げさな）アーキテクチャよりも、柔軟性やシンプルさといったものを求めたのは**「ルールをできるだけ作らずに属人的に判断する」**という企業文化を大切にしているからです。 
また別の観点からみれば、KARTEの管理画面がサブアプリごとにページを分けるような構造になっており、そもそもフロントエンドが大規模化しすぎないように設計されているということも、このような方針を採る際の後押しとなりました。
<h1>サンプルコード他</h1>
何はともあれコードで説明するのが一番です。 
せっかくなので、冒頭でご紹介したToDoアプリのコードをStoreパターン的に実装してみます。
<script async src="//jsfiddle.net/atsushiss15/fgone3us/1/embed/js,html,result/"></script>
この例ではStoreによって状態（state）と処理（addToDo, removeTodo）の共有を行っています。 
一見コードが増えたようにも見えますが、複数コンポーネントで状態や処理の共有が行われるようになるとStoreパターンによる恩恵を享受できるはずです。
<h2>イベントの通知について</h2>
イベントの通知については幾つかの手段が考えられますが、次の２つをケースにより使い分けるのが良いのではないでしょうか。
<h3 style="color:#494a50;">1. StoreのEventEmitterを利用してEventの通知を行う</h3>
<pre><code># Store側
{EventEmitter} = require 'events'
class XxxYyyStore extends EventEmitter
# 省略...
</code></pre>
<pre><code># コンポーネント側
# ...省略
methods: -&gt;
 hogeAction: -&gt;
 # 別vueや別componentに変更等を通知
 xxxYyyStore.emit 'conditionChanged', {}

 compiled: -&gt;
 # 別vueや別componentからStore経由でイベントハンドリング
 xxxYyyStore.on 'conditionChanged', () -&gt;
 # handling
</code></pre>
<h3 style="color:#494a50;">2. watchやcomputedを利用して間接的にイベントハンドリングを行う</h3>
```
# Store側
# ...省略
watch:
 'xxxYyyStoreState.todos': ->
 # 共有状態に変更があった場合の処理
computed:
 isEmpty: ->
 @xxxYyyStoreState.todos.length is 0 
```
複雑な変更と明示的なタイミングの制御が必要なものは **1.** の方法で個別にハンドリングし、そうでない場合は **2.** の方法でハンドリングするといった要領で使い分けてみると良さそうです。
<h2>その他に留意すべき点</h2>
また、Vue.jsでStoreパターンを構築する際には以下の点にも留意するようにしてください。
<h3 style="color:#494a50;">1. XxxYyyStore.stateに余分なものを入れない</h3>
XxxYyy.stateは、Storeの外に公開されるオブジェクトです。Vueのデータ更新監視の対象になるので、あまり大きなものを入れないほうが良いです。
<h3 style="color:#494a50;">2. XxxYyyStore.stateを置き換えない</h3>
一つのStoreインスタンスを複数箇所で使い回す形になります。
constructorで作ったstateを、複数のVueコンポーネントで監視するようになるので、state自体を置き換えるコードがあると、値の追跡が正常に行われなくなります。
```
# まずい例
constructor: ->
 @state=
 value: ''
updateXxx: (newState) ->
 @state = newState # <- @stateを置き換えているので、更新が拾えなくなる
```
<h3 style="color:#494a50;">3. 基本的に$broadcast, $dispatch, $parent, $childは使用しない</h3>
これらの仕組みはほとんどStoreパターンで補うことができるので、コンポーネントの密結合・複雑化を防ぐためにも使うべきではありません。props（データを子コンポーネントに明示的に伝達する仕組み）に関しても使用を必要最小限に抑えてください。
 
さて、簡単なサンプルコードを使って説明してきましたが、なんとなく感覚は掴んでいただけたかと思います。実際にはもう少し考えなければならない事があるのですが、基本的には上記のシンプルなパターンを拡張していくイメージになります。
<h1>Storeパターンに移行した感想</h1>
<h2>良かった点</h2>
<ul>
<li>サーバーとの通信処理や複雑なロジックがStore側に集約されたことで、コンポーネント側はVueが本来担うべき表示系の処理に集中できるようになった。</li>
<li>コンポーネント間の密結合が解消され、コンポーネントの再利用性が高まった。</li>
<li>全体的に見通しが良くなるのでロジックの改修等が楽に行えるようになった。</li>
</ul>
<h2>考えるべき点</h2>
<ul>
<li>重い初期化処理に対しては適宜遅延させるなどの工夫が必要になる</li>
<li>Storeでの処理後にコンポーネント側で後処理を行う際は、コールバックで行うのか、状態の変更を監視して行うのか、イベントをハンドリングして行うのか、などを適宜使い分ける必要がある</li>
<li>状態の更新フローに関する制約をどこまで設けるかは再考する必要がある</li>
</ul>
所感としては、Storeパターンへの移行の目的としていた点はおおよそ満たせたのではないかと感じています。もちろんまだまだ試行錯誤が必要な点はあると思うので、より良いアーキテクチャを目指して日々改善していきたいと考えています。
<h1>最後に</h1>
ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
 (function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "https://platform.wantedly.com/visit_buttons/script.js";
 fjs.parentNode.insertBefore(js, fjs);
 }(document, "script", "wantedly-visit-buttons-wjs"));
</script>

Vue.jsを用いたコンポーネント指向のフロントエンド開発において弊社が導入したStoreパターンについてご紹介します。

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

<html><head></head><body>みなさん、ごきげんよう。プレイドの@akobaです。 
プレイドではCXチームのエンジニアとして、プロダクトの機能開発、ならびに弊社のウェブ接客プラットフォームKARTEで提供するアプリケーションの開発を行っています。 
今回は、KARTEでできることを広げる試みの一環として、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。 
具体的には、ユーザーの閲覧履歴、レビュー／コメント機能、今この記事をxx人が見ていますといった機能を作ってみました。 
通常ネイティブアプリ向けとして使われることが多いFirebaseですが、Webブラウザ上でも色々と面白いことができます。 
この記事が皆さんの開発の参考になれば幸いです。
<h2 id="目次">目次</h2>
<ul>
<li>Firebaseとは</li>
<li>Firebaseにデータを貯めていく</li>
<li>ページ内でユーザーの情報を共有する</li>
<li>リアルタイム機能を使う</li>
<li>KARTEを使ってアプリを配信</li>
<li>まとめ</li>
</ul>
<h2 id="Firebaseとは">Firebaseとは</h2>
<a href="https://firebase.google.com/" target="_blank" rel="noreferrer">Firebase</a>とは、最近大きく注目を集めているMBaaS(Mobile Backend as a Service)、つまりモバイル開発のためのクラウド・ベースのバックエンドサービスです。2014年にGoogleに買収され、Google I/O 2016で新バージョンが発表されました。 
ここでのバックエンドとはDB、認証、ストレージ、解析、メッセージングプラットフォームなど（詳細は公式サイト参照）で、主にネイティブアプリ向けのプラットフォームとして提供されています。 
ただし、Web用のSDKも準備されており、今回はこのSDKをWebサイト上で使ってみたいと思います。
SDKといっても、Webページに下記のようなタグを貼るだけです。 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5c996e6-805a-4054-8eaa-d1d6bbab1717/-2016-09-29-7.23.18.png" alt="web-setup-code"> 
（xxxの箇所はFirebaseのプロジェクトによって異なります。詳細は<a href="https://firebase.google.com/docs/web/setup" target="_blank" rel="noreferrer">こちら</a>）
Firebaseには様々な機能が用意されていますが、今回は<a href="https://firebase.google.com/docs/database/" target="_blank" rel="noreferrer">Realtime Database機能</a>にフォーカスして使ってみます。 
この機能、BaaSなので当然なのですが、自分でサーバーを立てる必要がなく、上記のタグを貼るだけでブラウザからアクセス可能なKVSとして利用できます。 
DBとしての特徴は主に下記となります。
<ol>
<li>DB全体が1つのJSON treeとして扱える</li>
<li>データの更新時、データを使っている各クライアントにリアルタイムで同期される</li>
<li>オフライン時もクライアント側でデータを保持し、オンラインになった時点でオンラインデータとマージされる</li>
</ol>
1のために、個別のデータを更新するにはそのパスを指定して更新、全体を更新するにはルートパスに大きなJSONを1つ送るだけで済みます。（ただし大きすぎるJSONについてはそのまま送信はできないので、細かく分割して送信する<a href="https://github.com/firebase/firebase-import" target="_blank" rel="noreferrer">ツール</a>が公開されています。）また読み込みの際も、全体のデータが欲しいのか、一部のデータが欲しいのかを、参照するJSONのパスを指定することで細かく指定することができます。 
2は色々と面白いことができそうですね。 
3もかなり便利そうですが、今回は使いません。
<h2 id="Firebaseにデータを貯めていく">Firebaseにデータを貯めていく</h2>
では、実際にFirebaseのDBを使ってみましょう。
FirebaseのDBはKVS(Key Value Store)なので、なんらかのキーを軸にデータを集めていくことになります。 
キーとして もっともよく使われるのはユーザーID（ユーザー軸）でしょう。それ以外にWebページのURLやWebページ上のアイテム・コンテンツID、もしくは地域やユーザー属性のようなものをキーにしても面白いかもしれません。 
今回は、ユーザー軸とWebページ軸の情報をFirebaseに集めることにします。
まず最初にWebページ軸の情報。
<pre><code class="hljs">var pagePath = 'page/' + encodeURIComponent(location.pathname).replace(/\./g, '%2E');
firebase.database().ref(pagePath)
 .set({
 image: image,
 title: title
 });
</code></pre>
ページのURLパスをキーとして、ページ毎に、そのページのタイトルと画像URLを保存してみます。<a href="http://ogp.me/" target="_blank" rel="noreferrer">Open Graph</a>の値などを入れておくといいですね。 
<code>page/</code>の部分はなんでもいいですが、RDBのテーブル名のように、データの種類を区別するためにつけておきます。また、Firebaseのキー名には<code>., $, #, [, ], /</code>は使えないのでパーセントエンコードしておきます。（が、以下では簡略化のためにエンコードのコードは記載しません）
次にユーザー軸の情報。単純に、閲覧したページのURLを保存しておきましょう。
<pre><code class="hljs">var userPath = 'user/' + userId;
firebase.database().ref(userPath + '/visit/' + location.pathname)
 .set({
 timestamp: parseInt(new Date() / 1000)
 });
</code></pre>
ごちゃっとしていますが、<code>user/[ユーザーID]/visit/[URLパス]</code>に<code>timestamp</code>という値を書き込んでいます。 
<code>userId</code>の箇所は、なんらかの形で保持しているユーザー毎のIDを使用します。
ユーザーがページを見るたびにその情報をFirebaseに書き込んでいくと、FirebaseのDBには下記のようにデータが溜まっていきます。
<pre><code class="hljs">{
 "page" : {
 "%2Fproducts%2Fdetail%2F12" : {
 "image" : "http://xxx.jpg",
 "title" : "xxx"
 },
 ...
 },
 "user" : {
 "akoba" : {
 "visit" : {
 "%2Fproducts%2Fdetail%2F12" : {
 "timestamp" : 1474968518
 }
 }
 },
 ...
 }
}
</code></pre>
こうやって、ユーザー毎にそのユーザーが見たページのURL（パス）、ページ毎にそのページのタイトルと画像を保存しておくと、最近見たページのリスト（いわゆる閲覧履歴）が表示できます。
まず最初に、自分のユーザー情報を取得します。
<pre><code class="hljs">firebase.database().ref(userPath)
 .once('value')
 .then(function(snapshot) {
 var myUserData = snapshot.val();
 ...
 });
</code></pre>
<code>once</code>とは、このタイミングでデータを一度だけ取得するということです。更新の監視は行いません。
myUserDataには上記のJSONの一部、下記のようなデータが入っています。
<pre><code class="hljs">"visit" : {
 "%2Fproducts%2Fdetail%2F12" : {
 "timestamp" : 1474968518
 }
}
</code></pre>
このvisit以下の各キーについて、ページの情報を取得すると、過去閲覧したページの画像とタイトルを表示できます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/91964ea1-84de-4013-8086-3e5df2208773/-2016-09-28-19.07.08.png" alt="recent_items">
1点注意ですが、当然閲覧履歴はどんどん溜まっていきます。残念ながら、現状FirebaseのDBにはexpireの機能がないようなので、ある程度の数を超えたらtimastampの古いものから消していく等の対応が必要です。
<h2 id="ページ内でユーザーの情報を共有する">ページ内でユーザーの情報を共有する</h2>
先ほどの例は、ユーザーを軸に、ページの情報を取得しましたが、その逆も可能です。 
たとえば、
<pre><code class="hljs">firebase.database().ref(pagePath + '/review/' + userId)
 .set({
 nickname: nickname,
 comment: comment,
 starCount: starCount,
 timestamp: parseInt(new Date() /1000)
 });
</code></pre>
のような値を書き込むことで、ページにユーザーレビューを投稿する機能も実装できます。 
ユーザーレビューまで行かなくても、書き込みを例えばサイトのスタッフのみに制限しておけば、各ページ、そのページに表示されている商品や記事への、スタッフのコメント機能が実現できます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2a0b8dd-d4d3-4a52-8478-60aa1ef0f73f/-2016-09-27-23.09.33.png" alt="staff_comment">
スタッフは、実際に自分のサイトにアクセスして、該当のページでコメントを入力するだけです。 
こういった機能はいかにもウェブ接客という感じですね。
<h2 id="リアルタイム機能を使う">リアルタイム機能を使う</h2>
Firebaseの特長でもある、リアルタイムのデータ同期機能を使ってみましょう。 
今度もページ軸で、
<pre><code class="hljs">firebase.database().ref(pagePath + '/visit/' + userId)
 .set({
 timestamp: parseInt(new Date() /1000)
 });
</code></pre>
そのページを見ているユーザーをどんどんページ情報に追加していきます。 
ページ側では、そのページの情報を下記のように取得します。
<pre><code class="hljs">firebase.database().ref(pagePath + '/visit')
 .on('value', function(snapshot) {
 updateUserCount(snapshot.numChildren());
 });
</code></pre>
先ほどの<code>once</code>と違い、<code>on</code>では対象の値が更新されるたびに都度、指定した関数が実行されます。<code>numChildren</code>でデータ内の子要素の数を取得し、<code>updateUserCount</code>で表示するユーザー数の値を更新します。 
こうしておくと、表示されているユーザー数が、新しくユーザーが来訪するたびに増えるようになります。
ということで、今このページに出ている↓は、実際にFirebaseで作っています。 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7e1e941a-c86e-4a93-8cd1-8c06e596093f/-2016-09-28-18.57.14.png" alt="">
なんか出てたけど消しちゃったよという方は、このページをリロードいただくともう一度出るかと思います。
こちらについても、timestampをチェックして一定時間以上前のユーザーは削除していく等の対応が必要です。このページに設置してあるものについては、ページの閲覧から10分以上経過したユーザーを削除しています。
<h2 id="KARTEを使ってアプリを配信">KARTEを使ってアプリを配信</h2>
最後に、こうやって作ったアプリケーションを、弊社のウェブ接客プラットフォームKARTEで実際に配信してみます。 
上記のサンプルでは、ユーザー軸、ページ軸ともFirebaseのDBを使ったのですが、KARTE自体がユーザー軸の解析を行っているので、ユーザー軸のデータの管理はKARTEに任せることができます。 
したがって、KARTEを使って上記のアプリを配信する際は、下記のような役割分担となります。
<ul>
<li>KARTE：いつ・誰に・どうやって配信するかを制御。ユーザー情報を管理</li>
<li>Firebase：ページ毎の情報を管理</li>
</ul>
KARTEでは、通常あらかじめ用意されたテンプレートを利用し、色やテキスト、画像等を差し替えるだけでコンテンツが配信可能です。しかし、もちろんフルカスタマイズすることも可能で、HTML、CSSに加えてJavaScriptの実行も可能な自由度の高いプラットフォームとして作られています。 
したがって、今回のような外部のサービスを利用することも、そのためにそのサービスのタグを呼び出すことも可能です。また、今回の記事では触れていませんが、いわゆるウィジェットを作る用のAPIも用意されています。
実際に作成しているエディタの画面です。 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1462c55a-bbfe-4b20-b725-232def824886/-2016-09-27-16.44.49.png" alt=""> 
HTML、CSS、JavaScriptが自由に編集できるので、ここにFirebaseを使用するコードを書きます。
先ほどご紹介した、このページで表示しているユーザー数のカウンターも、KARTEを使って配信しています。
<h2 id="まとめ">まとめ</h2>
最後は少し駆け足になってしまいましたが、Firebaseを使って簡単にWebサイト上で動作するリアルタイムアプリケーションが作れる様子、またそれをKARTEを使ってWebサイト上に自由に配信できる様子が伝わりましたでしょうか。 
実際、Firebaseでアプリケーションを開発する際には、事前に用意する必要があるものもほとんどなく、思い立ったタイミングでサクッと簡単に機能を実装できてしまいます。
ウェブ接客プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。 
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！
<div class="wantedly-visit-button" id="wantedly-visit-buttons-wjs" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
 (function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "https://platform.wantedly.com/visit_buttons/script.js";
 fjs.parentNode.insertBefore(js, fjs);
 }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
</body></html>

今回は、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた | PLAID engineer blog

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

こんにちは。プレイドインターンの岡田です。
2月初めごろからエンジニアのインターンをさせていただいています。 
未経験で飛び込んだエンジニアでしたが、優しく面白い社員さん達に技術を教わりながらbugfixや機能追加などのお仕事をさせていただいてます。
さて、今回はプレイドの講演があったので、9月13日(火)に慶應義塾大学 日吉キャンパスで開幕した<a href="http://db-event.jpn.org/webdbf2016/index.html">WebDB Forum 2016</a>に参加してきました。その様子をご紹介します。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac15a42d-a576-45ce-a1ae-f45aeae42bc1/kanban-1.jpg" alt="">
<h2>WebDB Forumとは</h2>
WebDB Forumは情報処理学会データベースシステム研究会、日本データベース学会、電子情報通信学会データ工学研究専門委員会が主催で、WebとDB技術に興味のある研究者、大学院生、学部生、企業やオープンソースコミュニティの技術者が最新研究動向や成果について議論し、交流を行うイベントです。
参加者は例年300から400人で、半数以上はWebとDB技術において最先端の研究を行っている大学院生・学部生のようです。
プレイドはこのイベントのスポンサーをさせてもらっているので、受付後にもらえる紙袋やパンフレットの裏に社名が載っています！Googleや東芝と並んでいるのが嬉しいですね！
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d862d412-986e-47a9-a635-aa28e0080d9e/IMG_8576.jpg" alt="">
<h2>WebDB Forumの様子</h2>
テーマはビッグデータ、IoT、機械学習、データ分析、データ構造など様々で、テーマごとにいくつかの会場に分かれて同時に複数のセッションが行われていました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a152a6f-6d04-4002-9354-99b750da29eb/---2016-09-13-13-54-20.jpg" alt=""> 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4899c171-7d8f-4c68-a894-113d7d18e1fc/---2016-09-13-12-35-04.jpg" alt="">
技術報告のほかに招待講演「ビッグデータと秘密計算」と「データ処理基盤」のセッションを聴講しましたが、どちらも質疑応答の時間にアツい議論が交わされていて圧倒されました。
休憩時間には大会議室前で飲み物と軽食が提供され、企業の方と学生が交流している様子や、聴講を終えた人たちがコーヒーを飲みながら意見を交わしている様子などが見受けられ、とてもいい雰囲気が漂っていました。
学生なら無料で参加できますし(学生証提示が必要です)、先生方の研究発表や企業の方の技術報告などが聞けて交流もできるなんて、とても素敵なイベントです。WebやDB技術に興味のある学生は次回、参加してみてはいかがでしょうか。
<h2>プレイドの技術報告紹介</h2>
<a href="http://blog-plaid.com/event/2642/?draftsforfriends=7UMtQCI4RFrXGZAcwN4sUDkz8aMNHORC">「GCP NEXT World Tour in Tokyo」でプレイドのGCP活用事例を紹介</a>した@makinoyが「ビッグデータの高速・分散処理」というテーマでKARTEの解析エンジンについて技術報告をしました。(当ブログでも<a href="/streaming-algorithm/">大規模データを解析するストリーミングアルゴリズムをサクッと見てみる</a>の記事を書いています)
タイトルは 「大規模分散リアルタイム解析エンジン Brook」
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dec0269-574a-40b1-a62f-91662015435a/P9130345.jpg" alt="">
私たちが提供している「KARTE」は、Webサイトへの訪問者をリアルタイムに可視化し、会員登録や購買に繋げるためのウェブ接客を可能にするサービスです。
KARTEはリリースから1年半で累計ユーザー数5億UUを解析してきました。
今回は、そのKARTEを支える独自解析エンジン「Brook (ブルック)」の紹介をします。
Webサイト上で現実のようなコミュニケーションをするためには、 「いま」の来訪者がどういう人で、どういう行動をしているのかを知る必要があります。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e5045c6-5827-4b31-ae18-25f1a1090447/---2016-09-13-14-54-11.jpg" alt=""> 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6f213078-db8c-483d-a6a5-89b43a3b4153/---2016-09-13-14-55-35.jpg" alt="">
それを実現するためには最新のユーザーの解析結果を計算し、結果に応じたアクションを決定するための時間を0.x秒にしなければなりません。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/afdc84b2-5736-429c-a143-47f0bcaa48e8/P9130347-2.jpg" alt="">
通常、データの解析には大きく2つの方法があります。
<ul>
<li>数時間〜数十秒で大量のデータをMapReduceするバッチ処理
<ul>
<li>BigQuery、 Prest、Spark、Hadoop</li>
</ul>
</li>
<li>1秒以内で直近の短期間少量のデータをMapReduceするストリーミング処理
<ul>
<li>Spark Streaming、Storm</li>
</ul>
</li>
</ul>
これらの技術では、Web上でリアルのようなおもてなしをするために1秒以内に大規模な蓄積データの解析結果を返すこと、またその結果を使ったアクションの実行を可能にしたいという想いを実現することができませんでした。
そこで、それを可能にするために開発したのが「Brook」です。
Brookではあらかじめ解析軸を一つだけ定義しておくことによって次のことを可能にしています。
<ul>
<li>実時間(秒以内)で、イベントログ送信と同期的に結果整合性のある解析結果に基づいたアクションができる</li>
<li>解析軸は固定だが、スキーマレスな解析、次元数が多い大きめのデータを扱える</li>
<li>全てが分散化されているので大規模のデータを扱えスケーラブルである</li>
</ul>
解析軸を複数設けずに1つに制限することで、0.x秒で全データの解析処理を行うことができ、KARTEでのリアルタイム接客が可能になっているのです。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d08565a2-5d40-4c83-ad48-017346c27445/P9130346-1.jpg" alt="">
20分の発表でしたが、他にもデータフロー、Hadoopと比較したBrookの特徴、スキーマレス統計処理、解析に用いているアルゴリズムなど、盛りだくさんの内容でした。 
学生さんをはじめ、聴講に来ていただいた方々ありがとうございました！
以上、WebDB Forumとプレイドの技術報告の様子をご紹介させていただきました。
KARTEやBrookのことを少しは伝えられたでしょうか。 
今回はあまり紹介できませんでしたが、KARTEやBrookの技術をもっと知りたい方は、ぜひプレイドのオフィスに遊びに来てください！
<h2>最後に</h2>
ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！

WebDB Forum 2016でKARTEを支えるリアルタイム解析エンジン「Brook」の発表をしてきました。