InsideFrontend 20190518
予定
WASM に投資してないのでどれだけ理解できるか不明
uknmr 希望 uknmr は来れた
電源なくてカフェにイン、あとリュックのチャックが壊れた
その後電源が交流スペースで取れるようになってた模様… Tw 泥臭そう、現場の失敗感
Quramy さん
BFF, MicroService, Node.js そのへんのキーワード拾ってる
日経、一番みたいやつ
サードパーティの広告スクリプトとの共存っぽい話
TypeScript: Why and how we adopted it at Slack
Slack Senior Staff Engr
当初 TS 反対派だった
簡単だったところ、難しかったところ、移行についのいろいろ
BattleField 1 は TS/React で書かれている
バックグラウンドのストリームも Node.js 製
Eleactron アプリもたくさんあるよね
Slack
C++ で書かれた Node 用モジュールがあってクラッシュする
トラブルシュートしづらい
多くの大規模な開発は JSDoc などでドキュメントを残したりして返却値や型などを担保している
こういった対応をしても Slack では課題がたくさんあった
5 merit
TS is superset of JS.
コンパイルされるので他のランタイムに依存しない
すべてのエディタでサポートがある
Slack には多くの npm モジュールがあるが pure js でも動く
そして型がある点
大規模な移行でもまずはリネームから始められる
.js to .ts
デモ
デモをしながらエディタの恩恵の説明など（VSCode）
配列の型定義ファイルは 500 行くらい、JS全てで 30000 行超え
メソッドをすべて知らなくても補完がきく
何よりコンパイル後のソースコードも複雑ではない点がうまい
可読性のある JS である
JS の場合存在しないプロパティやメソッドを使用してしまうケースが多くあった
型情報があったとしてもコンパイル後は消える
デモで言いたかったのは軽さがメインだったっぽい（気軽さとか）
一括 TS にした際に一度ではコンパイルできなかったが多くのエラーとバグを見つけることができた
ひとつひとつファイル単位で TS 化
KOA をサーバーフレームワークにしている
ドキュメントを開くこともなくエディタ越しに TS がサポートしてくれている
コミットしたときの信頼感が違う
デメリットとしては TSLint が弱い、ESLint に届かない
ただ、TSLint 廃止になった。移行しよう
大きなデメリット
多くの JS 開発者は型言語を使ったことがない（ネイティブアプリエンジニアならある）
難しい型演算、ジェネリックなどハードルは高いが学ぶことで有効に使えるようになる
Slack のもっとも難しい型情報の紹介など
Introduction to Lucet
EdgeCloudNetwork の未来について
組み込みコントローラーに Rust を使っている
EdgeCloud で WASM するよ
Lucet is 何
コンパイラ
input が WebAssembly のランタイム
主な目的は安全性
WebAssembly を使用するためのツールセット
asm.js というサブセットがあった
小さなバイナリファイル化して実行する
ブラウザ内でのサンドボックス実行の考え方で安全性が担保されている
TS = AssemblyScript
rustc
clang
WASI を Mozilla と策定中（わーじぃ）
WASM
ブラウザにデプロイする他なかった
多くのブラウザで実行できる環境は整った
ActiveXなど標準化からそれることがない偉業
Ahead of Time コンパイラ（JIT じゃない）
lucet
parser => verifier => translator => codegen => artifact
translator => 中間表現である「IR」に変換する変換器（低レイヤー）
codegen is 何
Cranelift
Mozilla が開発していた
lucet はこれなしでは不可能だった
IR => verifier => preopt => legalizer => postopt => register allocator => branch relaxer
低レイヤーの理解がうすすぎてわからない何も tkdn.icon
どちゃくそ複雑なことをしている
わたしの最初のタスクは C から Rust にしていくこと
ランタイムが安全に動くことを担保できた ＞ Rust
コンパイラがフレンドリーで開発の役にたった
Ahead of Time コンパイるで
パフォーマンスが良い
並列ワークフロー
Terrarium
demo
リクエストからボディやメソッドを取得してプログラマブルにいろいろレスポンスできる（語彙
DDos 攻撃にも使えてしまうのでは？
大丈夫、レートリミットや制限事項を設けている
悪意あるプログラムが配置されないよう仕組みがある
エッジコンピューティングの中で安全にプログラムが実行される環境がこれまでなかった
自分たちで作ろう、がなぜ lucet を作ったかの理由
formの送信ログから反省する、本当は必要だったvalidationや機能たち
sadnessOjisan さん
Recruit LifeStyle バックエンド？
写真、肩エラーwww
会社で React 勉強会などの育成など
サンプルアプリが事前に Tweet
Form どんなのある？（Lifestyleで）踏んだバグの話
HotPepper など
販促領域 HotPepper, !important 1590回！！！
予約動線などで Form 使用
業務支援領域 AirREGI
今回の話はこれ
レジに登録するフォームサンプル
カラーピッカー、バリデーション、行地下、トグル、行削除などなど
これらすべては日常使い（従業員が毎日使う）なのに複雑
SaaS なので解約率に注視している、なので
高いユーザビリティが必要
機能改善やスピードが求められる
高い QCD が求められている
最近 FE が結託してメンバーが多くなった
Airメイト
お店の経営アシスタント
管理業務の効率化と利益最大化支援
React/Next/Gatsby で開発
Formik でフォーム作ってる
State は Redux で管理している
フォームサンプル = 分析、提案の精度を上げるためデータ入力や設定が必要
めちゃくちゃ入力ミス
数値に日本語、空欄入力などなど
入力しづらい、修正しづらい、間違いに気づけない
数字に突然出てくる「お」0, O がキーボードで近い
input type number でモバイルはできるが
入力ではなくスライダーや inc/dec のボタンなどで回収
固まる入力
400行くらいのフォーム
入力のたびに rerender が走る、あるある
=> Pure, Memo で対応
Formik と Store とのバインディング
withFormik 等のエンハンサーは小さいコンポーネントに接続（rerender 防止）
コンポーネントのいちによっては解決できないのでビジネスサイドと相談
不正な値を送れてしまう
「お12」
バリデーションしなきゃ。でも結構複雑だよね
input type 指定、ライブラリ使用など
いつバリデーションするのか
入力中やってる
カスタマーサクセスの人
0 の半角のみ許可、変換してるときにはエラー
なので入力後にバリデーションすることにした（onblur)
input type は勝手にバリデーションする（ブラウザが）
間違いにきづけない
送信させない
入力ボタンに disable がよくあるパターン = a11y を害しているのでは？
フィードバックを返す
トーストで Success, Fail を出すようにしている（Lottie ？）
React 向けに
サーバーサイドでもバリデーション（当然）
当たり前のことだけどなかなかできないよね（会場ドッ
小数点、e など入力値によっては結構突破方法はあるよね
しょーもない、けど、UX バグって気づけ無いことが多い
フォームの実装 ＝ ビジネス要件
実装される機能が漏れがち
正解が難しい
気づける仕組みを作った
air-kit
ガイドラインやサンプルをウェブ上で確認できる
QA項目を UI に対するインテグレーションテストを実施
項目をテストケースとしたテスト
サンプルアプリにサンプルフォーム作りました
仕様が結構複雑
dom-testing-library という解決案
react-redux とつないでテスト可能
API につないだテスト可能
ロギング
Redux の Middleware で GA, Firebase に送った後に BigQuery で集計・分析
個人情報のマスクもしているよ
いつ、どのページで、何が起きたか
個人情報が絡むところからは取らない
ロギングの再生
ログの配列から再現する
Selenium で再生するプログラムを作った（ブラウザが実際に動く）
ログレポート、カスタマーヒアリングができれば不要かも
AMA
reduxのmiddlewareでactionを全部監視するとえげつない量のログが取れそうですが，その中から"役にたつログ"をどのようにフィルタリングしましたか？
レポートはPMからオーダーがあった
全部ログを送ってたわけではない
業務系のSassのUIをどんどん変えていくとユーザーのヘイトに繋がったりしませんでしたか？
カスタマーサクセスのヒアリングからオーダーがあって変えることが多い
なのでユーザーのロギングとカスタマーサクセスで話すのでそれはない
Logging, パフォーマンスには影響がありませんでしたか？
おっしゃるとおりです
onChange 毎に送ってたらそりゃやばい
onBlur だけで送っている、なのでいうほどパフォーマンスの問題はない
Form が多いとなると Form 用のコンポーネントの管理がかなり煩雑になる気がしています。コンポーネントの整理に何か工夫をしている、もしくは整理において感じている課題感などあれば知りたいです。
tkdn.icon
共通コンポーネント = Air-kit を使って管理しているのでまあ大丈夫
たくさんいろんなフォームがあるのでフォーム毎に作ってる！まじで
巨大なアプリケーションだが困ってはいない
共通化したほうがひどいことを見ることになった
<fieldset>/<legend> って使ってますか？
使ってないです
フォームのグループ化というのがあまり重要視されない、UI 的にも
バリデーションをデザインシステムに含めるうえでユースケースの増加やカスタマイズをどこまで許容するかが難しい気がするのですが、何か気をつけていたことはありますか？
バリデーションは要件次第
デザインシステム＝コンポーネントライブラリにはバリデーションのインターフェイスが持てるようになっている
ogからseleniumで再現するやつ、OSSになってたりします？ 社内ライブラリです？ めっちゃよさそうだったので、手元で試したいです
なってないです
ライブラリにはならない
ツールを作ったというだけ
JSON とコマンドをマップするだけのもの
GitHub に上げてるので御覧ください
使っているRedux middlewareはSagaでしょうか？
Saga です、メインは Saga を使っている
フロントエンドの Form をフロントエンドべったりで書いてしまうとサーバサイドで使いまわせなくなりそうなのですが、この辺りなにか知見や諦めはありますか？
ロジックが2重になるのはしょうがない、使い回しなどはない
クライアントサイドだけでバリデーションせざるを得ないもののほうが多い
フォームのエラーログはどのような仕組みで取得していたのでしょうか？
バリデーションはライブラリに validate という関数があったので引っ掛けている
バックエンドは Stackdriver
input の pattern 属性でのバリデーションは採用しなかった理由はなんでしょうか？
HTML（ブラウザネイティブ）のバリデーションは積極的に入れてない
チームにUXデザイナーはいらっしゃいますか？ また、Production環境へのデプロイ前後でABテストはされていますか？
UX デザイナーが1名、超できる
ブランドやシステムのデザインガイドラインもある
デザイン崩れなどは起きてしまっている
利用率、コンバージョンを求めるために AB テストはしていない
フォームのテスト項目洗い出し方法とか気になります！
チームの QA 項目書がある、QA の方が洗い出ししてくれている
テストなんとか流儀みたいな本をその人が読んでました
各フォームがどのようなデータの入力を意図しているかは、placeholderやツールチップなどを使うことによっても、ある程度ユーザーに説明、例示できるかと考えていますが、そのような点におけるポリシーなどはあるでしょうか？ (placeholderには必ず入力例を表示するなど)
ツールチップ、ヒントを見るなどフォームの使い方ガイドなどをヒンティングしている
placeholder 入力例を入れている（説明文はだめだよね
バリデーションエラーによって離脱/退会してしまったというような追跡はしていますか？
AirREGI との連携がうまくいかない、で退会は多い
ユーザビリティやフォームで退会するという例はあまり聞かない
バリデーションエラーの後に Submit されずに離脱というのはある
たくさんのイベントを取っておられるおられるようですが、離脱率計測はされてますか？例えばどこかまでは続けて入力されていたのに、あるところから途絶えた、など。
lasttime のログが作られる
そこから時間経過で新しいユニーク id を採番するようにしてあるのでわかる
BFFのDeveloper Experience
Quramy
FOLIO
FiNC で技術顧問やってる
開発補助ツールつくるの好き
会社紹介さらっと
BFF
結構手が上がったのでもうだいぶ普及しているキーワードですね
数年前に SamNewman が提唱したよね
特定の UX に紐づくものであり同じチームで保守されるべきもの
マイクロサービス抜きでは考えられないですよね
UX: Perf.API, UI
MicroService: domain driven, clean API, 技術的特異性
乖離した事情のためのBFF
Folio では
Web BFF, Mobile BFF
2つ存在している
30, 40 あるサービスから接続されている
なので BFF は複数のリクエストを各サービスにさばいている
今日は主に WebBFF の話
API Aggregation = 複数のサービスを束ねるという意味
SSR = React, Redux Univaersal に作ってある
BFF 導入で良いこといっぱい、のはずだが
フロントの仕事増えてる問題
SPA + BFF なので自分たちで API サーバもあるとやることが多い
今日のテーマは BFF をどうサクサク開発するには？
I/F 共有のための IDL
定義から各種言語へ生成できる（嬉しい
IDL を先に作って クライアント, BFF とバックエンドで共有
BFFにアグリゲーションレイヤーがあり、Thrift とつないでいる
開発体験として
開発中サービスの API はモックデータに差し替えたい
開発済みはテスト環境を利用したい
BFFのコードにモックコードは不要（不可知にしておきたい）
= 関心事の分離
BFF 種処理 ＝ 特定のマイクロサービスに処理を依頼、アグリゲート
モックデータは横断的関心事
これはつまりインターセプターのパターン
つまり AOP
Thrift の IDL ちょっと Java に似ている
生成されるクライアントは Promise を返すメソッドを備えたオブジェクトが作成される
クライアントを使う BFF
生成されたクラス（オブジェクト）のメソッドを呼び出す
プロクシしてモックを呼び出し可能になる
実データのモックデータ、リトライやほかの処理も挟める
ビルド時に確定する処理＝環境変数などでコードに落としている
実はモックのために作ったわけではない
Promise が解決されずに日に1回か2回発生していた
まじめにこれを解決せねば、という事情でインターセプターを作った
IDLが決まれば開発はすぐ着手できる、インターセプターでモックデータを参照できる
待って待って、BFF で DX も向上できるよ
MockManager というものが存在すれば UI からパイプしてモックデータを参照できるのでは？
金融商品の勧誘ではありません（会場ドッ
言わなきゃいけないらしい
テストするときにテスト用データに切り替えられるのでテストが非常に楽ちん
これいいなーすごい DX の向上、コスト削減につながりそう
StoryBook, Reg-suit, ESLint などなど、DX を上げることをやっているよ
FEの技術スタック自体が複雑になってきている
不便・複雑と感じたら少しずつエンジニアリングでかいけつできるのでは
AMA
API Aggregation で複数のエンドポイントを叩きに行くときに、そのうち1つのAPIでエラーが発生した場合(特にPOST/PUT)、ロールバックが難しいと思いますが、BFFでどのようにハンドリングしていますか？またそのようなケースに対してどのようにテストしていますか？
Read/Write は存在しても、Write/Write は起きないはずです
分散トランザクションを前提にあればバッチを作ったりなどする
開発組織として、大きな開発組織ではなくサーバーサイドエンジニア・フロントエンドエンジニアって分けてる感じではないチームの場合BFFの作成ってなにかメリットはありますか？ また、FOLIO社ではもともと初期開発時からBFFを挟む実装をしていたのでしょうか？
最初期からマイクロサービスとして開発していた
束ねるための BFF 、必然としての BFF
モノリシックに作って分解してもいいのかも
メリットがあったかどうかはまだわからない
ユーザにとって旨味が多くあるが一長一短ありそう
BFFにwebpackを絡めるとdev-server動かしにくかったりするんですが、スムーズなUI開発をどうやってるかとか知りたいです
しますねー苦手です
HMR 的なのは便利だけど、開発環境はやってない。StoryBook はデフォで HMR
FOLIO社の事例で良いのですが、Frontend Engineerはどれぐらい居ますか？ && 全員がBFFとReactを実装していますか？（片方のみ書いている人がいるのかどうか、それの良し悪しを聞きたいです）
全員が React BFF どちらも触っている
フロントエンドエンジニアはこのタイミングで 4 人
片方だけという人はいない
要求と実装を一括でやることで旨味がでているので分割したくない（今後も
FE <-> BFF 間の API はどのように定義していますか？
気になりますよね
正直ちゃんとできてないんですよね
要求と実装が一緒だからちゃんとできていない
FlowType の型システムを使っている
Redux Middleware の interface がマッチすればいいよね
改善する何かは入れたほうがよい
Can you advise on when to separate and when to combine BFFs for apps (mobile or web)?
最初から別れていて、くっつける分かれるとかはなかった
IDLを定義・作成している間、他の開発者は手が止まったりすることはないでしょうか？（特に新規開発時は）
もちろん手戻りする
ゼロイチの開発では
BFF をたてるとフロントの領域が広がるお話が出てきましたが、BFF 層の ロギングやプロセス監視、伴ったオンコール対応、CDN を使用していれば画面や API のレスポンスキャッシュ等いろいろやることが出てくると現場で感じています。FOLIOではどのように責務を分解されていますか？ tkdn.icon
CDN がうまいこと活用できていない
インフラとの棲み分けが難しい
Node.js でがりがり書いているとサービスメッシュで系でやってきたい
Thrift がちょっと対応しづらそう
リポジトリはどのように分けていますか？
BFF.自体はモノレポ
でかいのでわけたい
React のコンポーネントもいなくてええやろ
CI 遅い問題
AOPについてもう少し詳細に知りたいです、
TS デコレータ
Angular の構文によく出てくる DI
IDLはどの職務の人が書いていますか？
たたきをバックエンドが作ってる
フロントエンドが見てコミュニケーションする
引数やパラメータ、パターンチェックのため
開発初期に作成されたBFFを修正する場合どのようにフロント・バックで連携を取っているのでしょうか？またその際にBFFの信頼性が失われてしまうことが考えられるのですが、何か工夫はしていますか？
工夫はそんなにしていない
IDLをフロント側から定義してから、バックエンド側にその通りに開発してもらう必要があると思いますが、バックエンドの開発チームとのコミュニケーションに特に問題は発生してないのでしょうか？
先に口頭で説明
テーブル構造をお互い把握しているので
Loading Performanceとの向き合い方
泥臭い話を延々とします
日経 新卒2年目
企画もやるが、今は開発メイン
フロント, BFF, CDN
GoogleIO で Critical CSS の話
実は7月に2度めのリニューアルを控えている
今日の話
loding perf and nikkei
1秒のち円があると コンバージョン, PV... ビジネスインパクトがある.
KeyMetrics おさらい
これはいいや tkdn.icon
Lighthouse Perf 100
古い端末、スペックやOS、もろもろのデバイスでは
Throttling を変更すると落ちる
Good FMP
Bad TTI
ボタンを押しても反応がない時間がある
TTI の話
いつでも入力を受け付けられる状態
重たいスクリプトだと TTI まで 5.7s くらいあった
CPU idle = long task がない状態
主な原因が広告スクリプト
簡単に導入できる
ネットワークリクエストが複数回走る、コントロールできない
わかりみ tkdn.icon
確実に表示する
プロダクトのコードに影響されないような強い実装
iframe で表示
サイズが重たい、実行時間が編もたい
正確に計測する
ユーザに見えて初めてIMPはく
画面に入るまで広告を出さない
やっぱり広告はつらい、でも外せない
ステークホルダーが多いのでなんとかしてといってもなかなかできない
わかりみしかない…tkdn.icon
最適化しなきゃ
何かしらできることはあるはず
minify されたコードをデバッグ
スクリプトを呼び出す処理を探して
スクリプトをダウンロード
Fastly で配信（document.write を使わない？
カプセル化
クリエイティブのHTMLをパースしてこちら側で DOM 操作
Off the main thread
UI にかかわらないものは WebWorker
広告リクエストを Worker に回す
Comlink を使ってリクエストする
結構効果があった
最適化施策でクリエイティブが表示されないバグ
失敗時、例外時に通常処理になるようフォールバック
AdManager みたいなの必要なのかも tkdn.icon
ステークホルダーに合意も必要かも
パフォーマンス追求すると DX が低くなるケース（コンフリクト）
パフォーマンスの裏側
文字列テンプレート, VanillaJS, handlebars つらい
Linter が怒ってくれない？
何か手立てないかな？tkdn.icon
バグが出やすい
開発者の障壁になる
フロントエンド設計の刷新を行っている＞リニューアルに向けて
handlebars で バックエンドを書いていた
VanillaJS でフロントエンドを書いていた
から
バックエンドに JSX（+ TypeScipt）
フロントエンドに VanillaJS（会場、苦笑
静的なサイト ＝ VanillaJS で十分
CSR しなくて良い
Unversal に作る必要はない
クライアントでどうしたいというのはない
画像 lazyload, 日時の相対表示, などなど
フレームワーク導入を考えたが必要はなさそう
コンポーネント設計
React
State
仮想 DOM 、個人的には React など好きだがやめた
WebComponents を使うことにした
ウェブ標準だよね
生DOM操作より楽
SSRの実装と齟齬がない
JSX で customElements をラップ
React Hydration っぽくなる
若いのに良い話してる〜
AMA
パフォーマンスに取り組む価値をどのように事業側に説明し，工数をどのように確保していますか？ パフォーマンスは，機能要件に比べて優先度が引くことになる場面が多いような気がしていますが，ここまでやり込める秘訣はなんでしょう
宍戸さんがどこかで答えていた気がするtkdn.icon
優先度が低くなっている
機能要件が一番大事なので最適化は後回しされがち
業務中になかなか触れない
業務時間後に（会場ドッ
パフォーマンスこだわりがある
いかにユーザ目線でいることが大事なのか、布教をしている
社内 Qiita などいろんなステークホルダーに
広告SDKの解析と独自実装って契約や規約的に問題ないんでしょうか？（法務的な確認している感じなのでしょうか）
これはそう、きちんと問題ないようにしている
社内に広告チームがいる
ベンダーさんが外部に要るのでチームと話してやって良いという許諾をとっている
うちもやろtkdn.icon
CustomElementsのIE11のfallbackはどうしていますか？
IE11 への対応は…
polyfill が存在するのでそれ使ってる
わりきって、Edge/IE11 はまあもうええやろ感ある
IE11, Edge ユーザは多い
ただモバイル版がメインなので気にしてない
JSXでのサーバーサイドレンダリングをどのようにビルドしているかが全くわからないので教えて欲しいです！
TypeScript で Babel を通してビルドしている
あとは React の render
調査中とのことだったのでもしかすると調査中かもしれないのですが，worker を使うほどad系のロジックはCPU Heavy なのでしょうか？ postMessage するためのコストをとっても Worker を採用する価値あるのでしょうか？
AD の処理は Worker を使うほど CPU バウンドな処理なの？
メインスレッドから逃がすこと自体がポジティブ
ユーザに特化した広告を出す処理が CPU バウンドだった
結構価値はある
広告スクリプトの作成側に対して、こうして欲しい、こうだったら嬉しいとかあれば教えてください。善処します。
広告側からの質問ぽい
document.write をまずはやめてほしい
メインスレッドブロックよなーtkdn.icon
古い API はとにかく捨てていってほしい
ベンダーによるが、ドキュメントを開示してほしい
minify されたものを読むのがきついのでドキュメントください
広告スクリプトの作成側に対して、こうして欲しい、こうだったら嬉しいとかあれば教えてください。善処します。
使ってない、使う予定もない
今までが VanillaJS 生の WebComponents で十分
vanilaJSで開発するときにどうやって状態管理やevent handlerを行なっていますか？
リニューアルじゃなくて今の話
DOM のデータ属性を使って状態管理している
イベントハンドラなどは割と愚直に Vanilla 書いている
新しい技術を取り入れるときに、その技術が最適かどうかは、事前にデモなどを作って検証して、それからリリースするかどうかを検討しているのでしょうか？ 例えば、Reactを見送ったときは、実際に作ってみたうえで不要としたのでしょうか？
基本はコンセプト作ってから決定している
React のときは、Preact で作ってみた
つらみがどんどん出てきた
最終的に必要はないと判断
途中までやったがつらくてやめた
SSR は Preact
リニューアルを前回から考えるとかなり早いなと感じたのですが、リニューアルに踏み切った背景をもう少し教えていただいてもよろしいでしょうか？
我々の意思ではなかった
誰かの鶴の一声
自分たちが作り直したいというのではない
なんか黒いものがあるtkdn.icon
全ては納得に優先する話かなあtkdn.icon
広告スクリプト以外のパフォーマンス阻害要因はありましたか？また、どのような対応を行いましたか？
マーケ、プロも用にサードパーティスクリプトを入れてほしいと言われる
本当に必要なのか？ということを返して拒否している
お互いの利害をすり合わせてやるかやらないか決める
document.writeを使うようなADのサービスは近年少ないと思うのですが、ADサーバー自体のリプレイスなどは検討されなかったのでしょうか？
絡む人が多いのでいまいま検討していない
web componentsとJSXで記法がぶつかったりバグったりはあるのでしょうか？
実際には Preact なので、React はわからないがコンフリクトが発生するということはなかった
結果、Vanillaに戻した際に以前と進化した部分はありますか？
customElements を使い始めた
以前の Vanilla と比べてやりやすくなった
Nikkei 的には今の所のベストプラクティス