- 第1回のテーマは 「APIの役割の多様化」 です！
- アプリやWeb、スピーカーなど出面の多様化
- 海外進出によるリージョンの多様化
- 自社や開発者など利用者の多様化
- といった多様化や変化に対して、APIやサーバーサイドをどのような思想で開発しているかを語り合うことで、これからのサーバサイドのあり方について一緒に考えられる夜にしましょう！
- 遅刻のため，割愛
リージョンごとのソースコードのフォークについて詳しく
- 各国でやってることが別々になってきた
- US／UKで求めてるものが違うので，構成も異なる
- マイクロサービスが沢山
- メルカリボックス？
- APIフォーク
- アプリ
- コード
- 組織
- 日本とアメリカでコンフリクトが発生
- Microservice化のアプローチの違い
- 概要
- 施策の妥当性
- 仮設の検証
- 上記のためにユーザーをサンプリングしてUIやデータ構成を検証するもの
- 注意事項
- 結果に対して相互作用をもつテストは同時並行はNG
- 計測結果に影響が出る
- 施策以外の要因によってKPIが上下していないか
- ユーザーが少ないとばらつきやすい
- 季節が変わると違う動きをしてしまうとか
- 対象ユーザーを計測してから見たほうがいい
- 結果に対して相互作用をもつテストは同時並行はNG
-
Push配信回数調整テスト
- 一番継続率に聞いてくるか
- 証明されるまで検証
-
カテゴリ内の記事表示出し分け
- 新規ユーザー向け
- 更新日時の鮮度
- 特定カテゴリを多めに表示
-
検索結果のソート機能
- おすすめ
- 古い
- 新しい
- 検索ワードの合致率
- ユーザーの行動がどう考えるのか
- 全体ユーザーに対して何％割り当てるか
- 重複なく実行するための機能
- ABテストそのものをどうするか
- 1個のイベントに付き1つのランダムなKeyを降る
- テストケースをどの程度実行するか
- 個別のケースを保存
- 機能導入を大胆に
- 本当に効く施策ってなんだろう
- 自分の思い込みをなくす
- 壊れないアプリが作れる
- 異常な動作があれば，割当率を変えればよい
- 納得度の高い機能が使える
- 余分な機能を切って行ける
- 必要な機能だけを提供できる
- 包含 排他の関係を明確した状態でA/Bテストを行うことで安全
- ユーザー体験が改善しない機能をリリースしなくて住む
- 双方が幸せ！
20:30 LINEにおけるデベロッパープロダクトシステムのマイクロサービス化
- 社内向け開発チーム
- 2011年よりサービス提供
- 台湾，タイ，インドネシアにも展開
- In-appのアプリケーション＆ネイティブアプリを提供できるアプリケーションPF
- 日本
- 新宿
- 福岡
- 京都
- 中国
- 韓国
- 別なむ
- 台湾
- タイ
- モノリシックなサービス
- スケーラブルに外部へ公開するAPIを整えて開発してこなかった
- 専任の担当者の不足
- UX＆DXに優れた機能を提供しないといけない
- グローバルな開発環境への対応
- 既存のユーザーを保ちつつ，プラットフォームを広げていく
- コンシューマー
- ビジネスパートナー
- ディベロッパー
- の順で優先順位
- 昔はもっと優先度が低かったのよ
- ディベロッパー
- ビジネスパートナー
- ビジネスパートナーとの内々のAPIだとクオリティが不要
- そのため，そこまでクオリティが高くないものに
- アーキテクチャの改善
- ボットAPI
- データ周り
- ざっくり
- 2015
- ログインのパブリックリリース
- 2016
- ボットサービスのマイクロサービス化
- 2017
- 簡単
- 2015
- 外部にAPIを公開したい
- 昔
- 同じAPIに携わるチームが国をまたがる
- お互いにあったことがないことも…
- インターフェースがバラバラ
- CEOくらいしか把握していない謎のAPI
- 同じAPIに携わるチームが国をまたがる
- 今
- CTO
- それぞれのチームで戦略的に開発展開
- 世の中に展開していった
- CTO
- 未来
- 開発チームそれぞれにグロース目標を！
- FIDOについて知ってもらうために発表されたそうですぞ
- 記憶
- ひみつのしつもん
- パスワード
- 所持
- 本人のみが所持しているもの
- 生体
- 指紋
- 虹彩
- 顔
- 利便性の問題
- 複数のパスワードを管理するのが面倒
- スマホで入力が面倒
- そもそも忘れる
- 安全性の問題
- パスワードを使いまわし
- 外部の脆弱性に依存してしまう可能性あり
- ユーザーリテラシーに依存
- リスト型攻撃などに弱い
- パスワードを使いまわし
- 解決法
- 安全性と利便性の向上
- 公開鍵暗号方式を使って所持認証と生体認証を実現するプロトコル
- 組み合わせることでよりセキュアに！
- 本人姓のの検証はローカルデバイス
- 公開鍵暗号方式
- 結果を送付
- Cookieやトークン
- 組み合わせることでよりセキュアに！
- 生体情報どうするの？
- 生体情報はサーバーに送られずローカルデバイスからでない！
- パスワード認証と何が違うの
- 認証する
- 認証結果とIDを送る
- IDの識別する
- 認証の結果でトークンを吐き出す
- 登録の流れ
- 登録開始
- チャレンジを発行し，送る
- 認証用の鍵ペアを生成
- 公開鍵とチャレンジをサーバーへ
- 登録完了
- 登録開始
- 認証の流れ
- 登録開始
- チャレンジを発行
- 認証機で認証し，OK
- 秘密鍵で署名
- サーバーへ送付
- 公開鍵で認証する
- 登録開始
- 認証する
- 策定中
- W3Cで検討中
- JSでAPIを叩くだけでFIDO認証を実現可能！
- FIDO認証って
- 認証プロトコル
- 生体情報はサーバーに送るの
- 送らない
- Web Authentication って
- ブラウザAPI！