$30 off During Our Annual Pro Sale. View Details »

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

hosomichi
March 28, 2018

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

hosomichi

March 28, 2018
Tweet

More Decks by hosomichi

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide