「Inside Frontend」に参加してきました

勉強会メモ
  • Inside Frontendに参加してきました。

inside-frontend.com

# タイトル 発表者
A-1 TypeScript: Why and how we adopted it at Slack Felix Rieseberg
A-2 Introduction to Lucet Adam Foltzer
A-3 Nuxt.jsで中規模サービスを統合した話 Koichi Sawada
Hajime Sasanuma
B-3 Making less of the web with feature policy Andrew Betts
C-3 デザインエンジニアとフロントエンド Shinichi Kogiso
A-4 formの送信ログから反省する、本当は必要だったvalidationや機能たち Yuta Ide
B-4 Web App Checklist 〜高品質のWebアプリケーションをつくるために〜 Kazunari Hara
Marina Toki
C-4 いちからデザインシステムを作ってみて学んだこと Kengo Haruno
A-5 BFFのDeveloper Experience Yosuke Kurami
B-5 strobo.fm公開収録 Shogo Sensui
Hiroki Tani
C-5 AbemaTVにおけるCSS is too fragile問題に対する解 Shota Kubota
A-6 世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト Mariko Kosaka
B-6 Loading Performanceとの向き合い方 Sho Miyamoto
C-6 品質と開発速度を両立させるために捨てたものと守ったもの Tsuyoshi Wada
Soichi Masuda

TypeScript: Why and how we adopted it at Slack

  • Felix Riesebergさん(Slack)

SlackのデスクトップアプリをTSに移行した話

  • Electronを使ってる
  • JSにバグが有るとクラッシュする
  • 構造化されたコードを書かないといけない
  • JSDocでドキュメント化
  • TSのよさ
    • 型がある
    • エディタの補助がきく
  • KOAをつかったけどドキュメントを開くことなく開発できた
    • 型と補完のおかげ
  • ESLintはすばらしいがTSLintはまだそこまでいってないe
    • ESLintがTSサポート始めた
  • JavaScriptしかやったことない人は型を知らない
    • そういう人にとっては型が難しい

Introduction to Lucet

  • Adam Foltzerさん(Fastly)

Lucet

Web Assembly

  • 低レイヤーの言語
  • 高パフォーマンス
  • ブラウザで動く
    • サーバでも動く
  • ブラウザ内でも安全に動く
  • WebAssemblyに変換できる言語
    • Rust, C, C++ TS, go, swift

Terrarium

  • RustやTSでかいたWebAssemblyをアップロードできるWebサイト

Nuxt.jsで中規模サービスを統合した話

  • Koichi Sawadaさん(yahoo)
  • Hajime Sasanumaさん(yahoo)

ebook japan

  • ebook japan + yahooブックストア
  • 開発期間約1年
  • 電子書籍販売サービス

開発体制

  • FE -> yahoo
    • yahooの資産が利用できる
  • API + DB -> ebook
    • 旧ebookの表船機能/データ
  • vue × Nuxt
    • vueはデザイナーが理解しやすい
    • ライブラリアップデートの手間削減
    • 初心者向けに日本語ドキュメント
    • Reactは(当時)ライセンスの問題
  • node + express

風土の違い

AtomicDesignへの挑戦

  • なぜ?
    • 新規回月なので途中導入より入れやすい
    • デザイン変更が多発が予想できたから
    • UIの一貫性を保ちたかったから
  • 苦労したこと
    • エンジニアとデザイナーの成果物が違う
    • スクラムと相性悪かった
      • 共通化していく作業の優先度が低く改善が疎かに

実装上の苦労したこと

  • apiから返ってくるデータが大きい
    • 使わない情報もたくさん入って返ってくる
    • 開発機関制約の中で大は小をかねた形
    • mixinsを使ってget処理をまとめた

リリース後の改善

体制

  • 動くものを見せるとこに集中しすぎた
    • エラー処理やシステム面での改善が放置気味
  • 経験豊富なエンジニアがいない
    • フロントエンドのサポートチーム追加
    • PRのレビューや実装の相談をうける

システム(パフォーマンス改善)

  • api呼び出しフローの改善
    • Promise.allできるものはまとめる
    • 描画語でいいものは描画後に取得
  • レスポンスサイズ削減
    • apiから取得したデータを削ってからclientに返す
  • JSファイル改善

いちからデザインシステムを作ってみて学んだこと

  • Kengo Harunoさん(yahoo)

デザインシステムを作るきっかけ

  • 多くのサービス多くの関係者
    • 20サービス関係者1000人(デザイナー/エンジニア/ビジネス/業務委託)
  • デザインがサービスでばらばら
    • 一貫性確保
    • デザイン開発効率化
  • 何を作る?

デザインシステム開発(デザイン編)

デザインガイドラインの策定

  • デザインの定義
  • 抽象的なスタイル定義
  • 具体的なルール

コンポーネントのリストアップ

  • 名前をつけていく(時間かかった)
  • 汎用的過ぎて名前むずい
  • 業務固有すぎてしっくりこない
  • 見た目にとらわれずどんな役割をもっているかを考えて選ぶ
  • 全員が納得するものにした(納得しない=適切でない)

スタイルガイドの制作

  • sketchでデザイン作成
    • あらゆるケースや状態を考慮しないといけないので大変だった
    • 種類×サイズ×状態分作る
  • デザインルールをドキュメント化
    • デザインルールを文字化するの難しい
    • 不明瞭な部分が残らないように
  • レビューは全員(4人)がOK出すまでやる
    • 共通認識を担保

デザインシステム開発(フロントエンド編)

コンポーネントライブラリの提供方法

  • 最初はhtml/css/jsでの提供
  • コーディング設計
    • BEM記法
  • Fractal
    • スタイルガイドジェネレーター
    • markdownで書ける
    • Handlebars + yaml
    • 静的サイトとして出力できる

方向転換

  • Reactを使ったプロジェクトが多い
  • Reactコンポーネントとして提供してほしいという要望
  • html/cssでの提供ではは活用しづらい

Reactでコンポーネントライブラリ

  • Storybookベースのものに変更
  • CSS Modules with Sass
  • TS
    • 有識者はいなかった
    • 性的チェックでエラー気づきやすい
    • エディタ補完便利
    • 型でデザインをより厳格化できる
  • スタイルガイドをGatsbyで静的ページとして作った

振り返って

  • デザインから実装までこなすのはとても大変だった
  • デザインシステムは巨大なプロダクト
  • 使う人とのコミュニケーションが大事

BFFのDeveloper Experience

  • Yosuke Kuramiさん(FOLIO)

BFF

  • Backends for Frontends
  • UX視点
    • パフォーマンス
    • UIに必要十分なAPI
    • 統一したUI
  • マイクロサービス視点
    • ドメインに注力
    • シンプルで再利用性の高いAPPI
    • サービスこどの技術得意製
  • これらをつなぐためにBFF

FOLIOのBFFの役割

  • API Aggregation
    • koa
  • SSR
    • react + redux

BFFのいいところ

  • バックエンドはドメインの開発に注力
  • フロントエンドはUIの要求をAPI化
  • SSRで高速化
  • => ただしフロントの仕事は増える

BFFを効率的に開発するために

バックエンドを待たない

  • IDL driven development
  • Interface Definition Language
  • FOLIOではThrift
  • IDLからコードを生成

サービスの仮データ

  • 開発中のAPIはモックに差し替えたい
  • 開発済みならテスト環境につなぎたい
  • BFFのコードはどちらにつないでも変わらないようにしたい
  • Direct Proxy

Developer向けの機能

  • BFFはフロントエンドがいじるので開発者用のAPI作ってUIを作ることもできる
  • stateを変える画面作って画面のバリエーションを試せたり

世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト

proxx.app

今の時代のガラケー

  • スマートフィーチャーフォンのこと
  • 機能
    • KaiOS
    • モダンブラウザ搭載
  • アフリカ、インド、インネシアではやってる
    • 安いから
  • 画面小さい、タッチスクリーンない、十字キー
  • キャリアがアプリを握っているからWebで提供するようにした方がいい

ゲームを作ってみる

  • Webの強みはドキュメント
    • その正反対をやってみる
  • ユーザのインプットが多いもの
  • あらゆるデバイスをサボーとするようなもの
  • => マインスイーパー的なもの

どうやって開発したか

  • チームスペック
    • フロントエンドエンジニア3人
    • kaiOS初めて
    • WebGL初めて
  • どこまでやるか
    • 1コードベースで作る
    • a11y対応も
    • パフォーマンス第一
  • コード
    • ゲームロジック
    • Stateサービス
    • UIサービス
    • 描画処理
    • 前者2つはWebWorkerで動かす
  • FW
    • WebWorkerとのやりとりはComlink
    • preact

github

github.com