Firebaseをフル活用したサーバーエンジニアレス新規事業プロトタイピング

by hosomichi

Slide 1

Slide 1 text

Firebaseをフル活用したサーバーエンジニアレス新規事業プロトタイピング 2018/03/27 by @jshosomichi

Slide 2

Slide 2 text

自己紹介せきようすけ a.k.a "ほそ道" Fringe81所属　フロントエンドエンジニア得意技：JavaScript / Elm / TypeScript / ReactNative

Slide 3

Slide 3 text

事業企画実現性検証事業化Go！いつもはローンチ向け開発をやることが多いのですが・事業化Go！が出た後の開発・拡張性があり安定運用出来る堅牢な基盤ローンチに向けた開発

Slide 4

Slide 4 text

本日お話する新規事業開発は下記、検証段階であります・事業化Go！が出る前の開発・アイデアが事業としてモノになるか検証するためのアプリ・品質的には最小機能で提供価値の検証が出来ればOK 事業企画実現性検証プロトタイピング事業化Go！ここを進めたい！ローンチに向けた開発

Slide 5

Slide 5 text

予選を勝ち抜いてきた、事業化の可能性がある３企画。これらを２ヶ月以内に事業化Go！の判断が出来るよう検証可能(実際に動く)なプロトタイプを開発せよ。事業企画事業企画事業企画今回のミッション実現性検証プロトタイピング事業化Go！

Slide 6

Slide 6 text

まだ利益を生み出せるかが不確実な段階のため、いったん少ない人数で３つのアプリ開発 in 2ヶ月を行うことに各プロダクトの企画者プログラマ (ワタクシひとり) デザイナ検証チーム

Slide 7

Slide 7 text

各プロダクトの企画者プログラマ (ワタクシひとり) デザイナ検証チームえっまだ利益を生み出せるかが不確実な段階のため、いったん少ない人数で３つのアプリ開発 in 2ヶ月を行うことに

Slide 8

Slide 8 text

プログラマ (ワタクシひとり) さて、３つのプロトタイプ、どうやって作ろう？

Slide 9

Slide 9 text

プロトタイプの設計時間/デザイン時間も考慮すると実際コードを書ける時間はより限られてくる。開発スピードを担保する為の戦略を考ねばなりません。プログラマ (ワタクシひとり) さて、３つのプロトタイプ、どうやって作ろう？

Slide 10

Slide 10 text

プログラマ (ワタクシひとり) さて、３つのプロトタイプ、どうやって作ろう？フロントエンド開発は得意なので速く作る算段は立つなぁプロトタイプの設計時間/デザイン時間も考慮すると実際コードを書ける時間はより限られてくる。開発スピードを担保する為の戦略を考ねばなりません。

Slide 11

Slide 11 text

プロトタイプの設計時間も考慮すると実際コードを書ける時間はより限られてくる。開発スピードを担保する為の戦略を考ねばなりません。プログラマ (ワタクシひとり) さて、３つのプロトタイプ、どうやって作ろう？バックエンドは学習コストを下げたいなぁフロントエンド開発は得意なので速く作る算段は立つなぁ

Slide 12

Slide 12 text

サーバエンジニアレス開発 with Firebase 強みを活かせる技術選定で戦を略そう！

Slide 13

Slide 13 text

モバイルアプリが強調されていますが、今回はブラウザです。 FirebaseはブラウザのWebアプリ開発まわりでも JavaScript SDKという形で同様に機能提供してくれています。ちなみに公式ページのトップでは

Slide 14

Slide 14 text

今回は下記５つのfirebaseサービスを利用しました今日はひとつずつ使いっぷりを紹介してまいります

Slide 15

Slide 15 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG Hosting

Slide 16

Slide 16 text

Hosting 指定したディレクトリ(省略時public/)配下のファイル群をコマンドひとつでWebサーバの配下に設置してくれます。検証時にユーザがアクセス出来るURLも用意してくれます。

Slide 17

Slide 17 text

Hosting 過去にデプロイしたバージョンにもGUI操作で戻すことが出来ます。

Slide 18

Slide 18 text

Hosting 自分で仕組みを作っていたひと昔前の感覚に立ち返ると、色々と戦を略すことができています。

Slide 19

Slide 19 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG Authentication 認証・サインアップ・サインイン・サインアウト

Slide 20

Slide 20 text

Authentication 色々な認証方法と、アクセス元の制御機能などを提供してくれています。Slack認証などもカスタムでできます。

Slide 21

Slide 21 text

Authentication エラーコードが内容を細かく判定してくれているので、ユーザーのメールアドレスが既に登録されているかなども下記のようにして確認可能でした。

Slide 22

Slide 22 text

Authentication いちどサインインすると、その状態をブラウザに保存してくれ、明示的なサインアウトをするまでその状態は保持され続けます。 ※サインイン状態の確認は非同期で行われるので、　画面遷移のハンドリングは自前でちょっと工夫が必要でした。 auth.onAuthStateChangedを呼んでおくと後でuser/errorが入ってくる仕組み

Slide 23

Slide 23 text

今回用意した認証システムは3プロトタイプでほぼ変更なしで使い回すことができました Authentication

Slide 24

Slide 24 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG Cloud Firestore 認証・サインアップ・サインイン・サインアウト DB ・インスタンス群の永続化

Slide 25

Slide 25 text

Cloud Firestore Databaseは２つの選択肢がありますが Uniposの開発時にRealtime Databaseを使った経験があったので今回は新しく登場したFirestore(β版)を使ってみようと思いました。

Slide 26

Slide 26 text

Cloud Firestore にじみ出るパワーアップ感プロトタイプ開発ならではの冒険しやすさ公式ドキュメントの比較

Slide 27

Slide 27 text

Cloud Firestore コレクション-ドキュメント-フィールドの階層で値を保持する。 MongoDBのような構造。ブラウザコンソール上でクエリを行う仕組みがいずれ出来ると嬉しいです。

Slide 28

Slide 28 text

Cloud Firestore batchというオブジェクトを引き回すことで、アトミックトランザクションを行うことができます。 (commitするまではset/updateを繰り返しても保存されない。)

Slide 29

Slide 29 text

Cloud Firestore 新規にIDを払い出すこともできます。非同期処理していないので、完全な一意性を確認・担保しているわけではないと思いますが。 ID被りをフォローしておけば、とても便利に使えます。

Slide 30

Slide 30 text

Cloud Firestore バリデーションはクライアントサイドとセキュリティルールの合わせ技で行いました例えば「Cityドキュメントのemailフィールドはユニークでなければならない」というアプリケーション制約があれば、一度データを取得して有無を確認。 Firestore側にセキュリティルールを設定しておくと違反時にはエラーを返して保存処理を防ぐことができます。

Slide 31

Slide 31 text

Cloud Firestore 永続化処理をクライアント側に担わせることで更に色々な戦を略すことができました。

Slide 32

Slide 32 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG Cloud Storage 認証・サインアップ・サインイン・サインアウトファイルサーバ・動的画像保存 DB ・インスタンス群の永続化

Slide 33

Slide 33 text

Cloud Storage システム内で登録される動的画像はCloud Storageに保存。ディレクトリを切ることも出来ます。

Slide 34

Slide 34 text

Cloud Storage アップロードするファイル名はクライアント側で設定する必要があります。今回はFireStoreを使ってIDを払い出して、そのIDを画像ファイル名とするなどしていました。

Slide 35

Slide 35 text

Cloud Storage ダウンロード時、ファイルの場所を示すURLしか持っていない場合は非同期APIで変換したURLでアクセスする必要があります。 tokenパラメータが付与されたURLが返される

Slide 36

Slide 36 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG Cloud Functions 認証・サインアップ・サインイン・サインアウトファイルサーバ・動的画像保存 DB ・インスタンス群の永続化イベントフック処理・データ変更を監視して通知送信

Slide 37

Slide 37 text

Cloud Functions さまざまなトリガーに対してあらかじめデプロイしたJavaScriptコードを実行することが出来ます。 (直接HTTPリクエストを受けるトリガーも作れます)

Slide 38

Slide 38 text

Cloud Functions 今回のプロトタイプでは主に firestoreのデータ更新をトリガーとしてメールの通知を行っていました。

Slide 39

Slide 39 text

Cloud Functions 更新前後のデータにアクセスすることが出来るので完了フラグの状態推移を見極めて、通知を送ることができ、便利です。

Slide 40

Slide 40 text

Cloud Functions 事前予想ではセットアップの手間がめんどくさいのでは。。などと思っていたのですが、コマンド一発でデプロイしてすぐに使えるようになりました。簡単！ local cloud functions JS

Slide 41

Slide 41 text

クライアント (ブラウザ) Webサーバ・HTML ・CSS ・IMG この構成で３プロトタイプの全要件を満たすことができました！認証・サインアップ・サインイン・サインアウトファイルサーバ・動的画像保存 DB ・インスタンス群の永続化イベントフック処理・データ変更を監視して通知送信

Slide 42

Slide 42 text

これで、 JavaScript知識を中心とした Noサーバインスタンス Noサーバサイドエンジニアの世界が実現しました

Slide 43

Slide 43 text

ビューロジック IOロジック Firebase ラッパー Firebase サービス API コードの再利用についても戦を略しました① Firebaseアクセスの汎用パターンをラッパー化することでプロトタイプAのコードをプロトタイプBで再利用 Firebase知識範囲

Slide 44

Slide 44 text

ビューロジック IOロジック Firebase ラッパー Firebase サービス API コードの再利用についても戦を略しました② 画面のロジックとFirebaseにアクセスする層を完全分離することでローンチ向け開発に移行した場合も、ビューロジックはそのまま使うことができるようにしています。外部アクセス知識範囲

Slide 45

Slide 45 text

略せる戦を略し倒し、結果的にフロントエンジニアひとり体制で・手を動かす時間は4週間・１プロジェクト目: 2週間・２プロジェクト目以降：1週間 3つのプロトタイプを構築しきることができました！かなり良いペース！(のはず)

Slide 46

Slide 46 text

Firebaseのおかげでこれからのプロトタイプも「任しとけ！」と自信を持って言うことが出来そうですありがとう、Firebase！