Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Firebaseをフル活用したサーバーエンジニアレス新規事業プロトタイピング
Search
hosomichi
March 28, 2018
Technology
1
2.4k
Firebaseをフル活用したサーバーエンジニアレス新規事業プロトタイピング
hosomichi
March 28, 2018
Tweet
Share
More Decks by hosomichi
See All by hosomichi
React_Nativeの_ルーティングばなし.pdf
hosomichi
0
2.2k
Elm is a good teacher
hosomichi
2
1.3k
改善React道
hosomichi
3
1k
ReactComponentのコンストラクタを追いかけて
hosomichi
8
3.6k
Other Decks in Technology
See All in Technology
Commitment vs Harrisonism - Keynote for Scrum Niseko 2024
miholovesq
6
1.1k
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
27
12k
Nix入門パラダイム編
asa1984
2
200
ABEMA のコンテンツ制作を最適化!生成 AI x クラウド映像編集システム / abema-ai-editor
cyberagentdevelopers
PRO
1
180
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
visionOSでの空間表現実装とImmersive Video表示について / ai-immersive-visionos
cyberagentdevelopers
PRO
1
110
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
430
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
170
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
330
生成AIと知識グラフの相互利用に基づく文書解析
koujikozaki
1
140
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
2.2k
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Agile that works and the tools we love
rasmusluckow
327
21k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
The Pragmatic Product Professional
lauravandoore
31
6.3k
A Modern Web Designer's Workflow
chriscoyier
692
190k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Building an army of robots
kneath
302
42k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Testing 201, or: Great Expectations
jmmastey
38
7k
GraphQLの誤解/rethinking-graphql
sonatard
66
9.9k
Happy Clients
brianwarren
97
6.7k
Designing for Performance
lara
604
68k
Transcript
Firebaseをフル活用した サーバーエンジニアレス 新規事業プロトタイピング 2018/03/27 by @jshosomichi
自己紹介 せきようすけ a.k.a "ほそ道" Fringe81所属 フロントエンドエンジニア 得意技:JavaScript / Elm /
TypeScript / ReactNative
事業企画 実現性検証 事業化Go! いつもはローンチ向け開発をやることが多いのですが ・事業化Go!が出た後の開発 ・拡張性があり安定運用出来る堅牢な基盤 ローンチに 向けた開発
本日お話する新規事業開発は下記、検証段階であります ・事業化Go!が出る前の開発 ・アイデアが事業としてモノになるか検証するためのアプリ ・品質的には最小機能で提供価値の検証が出来ればOK 事業企画 実現性検証 プロトタイピング 事業化Go! ここを 進めたい!
ローンチに 向けた開発
予選を勝ち抜いてきた、事業化の可能性がある3企画。 これらを2ヶ月以内に事業化Go!の判断が出来るよう 検証可能(実際に動く)なプロトタイプを開発せよ。 事業企画 事業企画 事業企画 今回のミッション 実現性検証 プロトタイピング 事業化Go!
まだ利益を生み出せるかが不確実な段階のため、 いったん少ない人数で3つのアプリ開発 in 2ヶ月を行うことに 各プロダクトの 企画者 プログラマ (ワタクシひとり) デザイナ 検証チーム
各プロダクトの 企画者 プログラマ (ワタクシひとり) デザイナ 検証チーム えっ まだ利益を生み出せるかが不確実な段階のため、 いったん少ない人数で3つのアプリ開発 in
2ヶ月を行うことに
プログラマ (ワタクシひとり) さて、3つのプロトタイプ、どうやって作ろう?
プロトタイプの設計時間/デザイン時間も考慮すると 実際コードを書ける時間はより限られてくる。 開発スピードを担保する為の戦略を考ねばなりません。 プログラマ (ワタクシひとり) さて、3つのプロトタイプ、どうやって作ろう?
プログラマ (ワタクシひとり) さて、3つのプロトタイプ、どうやって作ろう? フロントエンド開発 は得意なので 速く作る算段は 立つなぁ プロトタイプの設計時間/デザイン時間も考慮すると 実際コードを書ける時間はより限られてくる。 開発スピードを担保する為の戦略を考ねばなりません。
プロトタイプの設計時間も考慮すると 実際コードを書ける時間はより限られてくる。 開発スピードを担保する為の戦略を考ねばなりません。 プログラマ (ワタクシひとり) さて、3つのプロトタイプ、どうやって作ろう? バックエンドは 学習コストを 下げたいなぁ フロントエンド開発
は得意なので 速く作る算段は 立つなぁ
サーバエンジニアレス開発 with Firebase 強みを活かせる技術選定で戦を略そう!
モバイルアプリが強調されていますが、今回はブラウザです。 FirebaseはブラウザのWebアプリ開発まわりでも JavaScript SDKという形で同様に機能提供してくれています。 ちなみに公式ページのトップでは
今回は下記5つのfirebaseサービスを利用しました 今日はひとつずつ使いっぷりを紹介してまいります
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG Hosting
Hosting 指定したディレクトリ(省略時public/)配下のファイル群を コマンドひとつでWebサーバの配下に設置してくれます。 検証時にユーザがアクセス出来るURLも用意してくれます。
Hosting 過去にデプロイしたバージョンにもGUI操作で戻すことが出来ま す。
Hosting 自分で仕組みを作っていた ひと昔前の感覚に立ち返ると、 色々と戦を略すことができています。
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG Authentication 認証 ・サインアップ ・サインイン
・サインアウト
Authentication 色々な認証方法と、アクセス元の制御機能などを提供してくれてい ます。Slack認証などもカスタムでできます。
Authentication エラーコードが内容を細かく判定してくれているので、 ユーザーのメールアドレスが既に登録されているかなども 下記のようにして確認可能でした。
Authentication いちどサインインすると、その状態をブラウザに保存してくれ、 明示的なサインアウトをするまでその状態は保持され続けます。 ※サインイン状態の確認は非同期で行われるので、 画面遷移のハンドリングは自前でちょっと工夫が必要でした。 auth.onAuthStateChangedを呼んでおくと後でuser/errorが入ってくる仕組み
今回用意した認証システムは3プロトタイプでほぼ変更なしで使い回すことができました Authentication
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG Cloud Firestore 認証 ・サインアップ
・サインイン ・サインアウト DB ・インスタンス群の永続化
Cloud Firestore Databaseは2つの選択肢がありますが Uniposの開発時にRealtime Databaseを使った経験があったので 今回は新しく登場したFirestore(β版)を使ってみようと思いました。
Cloud Firestore にじみ出るパワーアップ感 プロトタイプ開発ならではの冒険しやすさ 公式ドキュメントの比較
Cloud Firestore コレクション-ドキュメント-フィールドの階層で値を保持する。 MongoDBのような構造。 ブラウザコンソール上でクエリを行う仕組みがいずれ出来ると嬉しいです。
Cloud Firestore batchというオブジェクトを引き回すことで、 アトミックトランザクションを行うことができます。 (commitするまではset/updateを繰り返しても保存されない。)
Cloud Firestore 新規にIDを払い出すこともできます。 非同期処理していないので、 完全な一意性を確認・担保しているわけではないと思いますが。 ID被りをフォローしておけば、とても便利に使えます。
Cloud Firestore バリデーションはクライアントサイドとセキュリティルールの合わせ技で行いました 例えば「Cityドキュメントのemailフィールドはユニークでなければならない」 というアプリケーション制約があれば、一度データを取得して有無を確認。 Firestore側にセキュリティルールを設定しておくと 違反時にはエラーを返して保存処理を防ぐことができます。
Cloud Firestore 永続化処理をクライアント側に担わせることで 更に色々な戦を略すことができました。
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG Cloud Storage 認証 ・サインアップ
・サインイン ・サインアウト ファイルサーバ ・動的画像保存 DB ・インスタンス群の永続化
Cloud Storage システム内で登録される動的画像はCloud Storageに保存。 ディレクトリを切ることも出来ます。
Cloud Storage アップロードするファイル名はクライアント側で 設定する必要があります。 今回はFireStoreを使ってIDを払い出して、 そのIDを画像ファイル名とするなどしていました。
Cloud Storage ダウンロード時、ファイルの場所を示すURLしか持っていない場合は 非同期APIで変換したURLでアクセスする必要があります。 tokenパラメータが付与されたURLが返される
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG Cloud Functions 認証 ・サインアップ
・サインイン ・サインアウト ファイルサーバ ・動的画像保存 DB ・インスタンス群の永続化 イベントフック処理 ・データ変更を監視して通知送信
Cloud Functions さまざまなトリガーに対して あらかじめデプロイしたJavaScriptコードを実行することが出来ます。 (直接HTTPリクエストを受けるトリガーも作れます)
Cloud Functions 今回のプロトタイプでは主に firestoreのデータ更新をトリガーとしてメールの通知を行っていました。
Cloud Functions 更新前後のデータにアクセスすることが出来るので 完了フラグの状態推移を見極めて、通知を送ることができ、便利です。
Cloud Functions 事前予想ではセットアップの手間がめんどくさいのでは。。などと思っていたので すが、 コマンド一発でデプロイしてすぐに使えるようになりました。簡単! local cloud functions JS
クライアント (ブラウザ) Webサーバ ・HTML ・CSS ・IMG この構成で3プロトタイプの全要件を満たすことができました! 認証 ・サインアップ ・サインイン
・サインアウト ファイルサーバ ・動的画像保存 DB ・インスタンス群の永続化 イベントフック処理 ・データ変更を監視して通知送信
これで、 JavaScript知識を中心とした Noサーバインスタンス Noサーバサイドエンジニア の世界が実現しました
ビュー ロジック IOロジック Firebase ラッパー Firebase サービス API コードの再利用についても戦を略しました① Firebaseアクセスの汎用パターンをラッパー化することで
プロトタイプAのコードをプロトタイプBで再利用 Firebase知識範囲
ビュー ロジック IOロジック Firebase ラッパー Firebase サービス API コードの再利用についても戦を略しました② 画面のロジックとFirebaseにアクセスする層を完全分離することで
ローンチ向け開発に移行した場合も、 ビューロジックはそのまま使うことができるようにしています。 外部アクセス知識範囲
略せる戦を略し倒し、 結果的にフロントエンジニアひとり体制で ・手を動かす時間は4週間 ・1プロジェクト目: 2週間 ・2プロジェクト目以降:1週間 3つのプロトタイプを構築しきることができました! かなり良いペース!(のはず)
Firebaseのおかげで これからのプロトタイプも 「任しとけ!」 と自信を持って言うことが出来そうです ありがとう、Firebase!