「Mercari x Merpay Frontend Tech Talk vol.3」に参加してきました

  • Mercari x Merpay Frontend Tech Talk vol.3に参加してきました。

mercari.connpass.com

タイトル 発表者
Creating Serverless CMS from Scratch @sottar_
Vue.jsでのCSS設計 @tacamy
The Challenge of Web re-architecture using GraphQL and Apollo @lightnet328
Practical tips for making a global EC site @yayoc_

Creating Serverless CMS from Scratch

  • @sottar_さん

キャンペーンのページを作るまで

  • 従来のフロー
    • PMからどんなターゲットでどんあんことをしたいか伝えられる
    • デザイナーがコードを書く
    • フロントエンドエンジニアがレビューする
    • PMに返して問題なければリリース
  • 課題
    • デザイナーがコード角の大変(pug/css)
    • フロントエンドエンジニアがレビューするの大変
    • 一文字とか一部分変えるだけでもGitHubでフロー回さないといけない
  • キャンペーンページ作るのに時間かかる
    • 一ヶ月に1,2本くらいしか作れない

CMSを作った

  • コンポーネントを作ってCMS上で組み合わせるようなものがほしい
  • 必要なページ
    • キャンペーンの一覧ページ(過去に作ったものとか)
    • 編集ページ
  • なんでOSSを使わなかったか
  • 考えないといけないこと
    • 権限周り
    • セキュリティ
    • 履歴管理
    • プレビュー
    • => いろいろあるけどまずはMVPを作ってさわってもらう

アーキテクチャ

  • S3にCMSページの静的ファイルを配置
  • Cloud Storageにキャンペーンページを置いておいてそれをdynamic importして表示
  • GCPAWS混ざってる
    • 基本はGCPを使ってる
    • 社内版GitHubPages的なものをS3で作ってる
  • 認証はAuth0

Vue.jsでのCSS設計

  • @tacamyさん

コンポーネント

  • 機能が自己完結する
  • 再利用できる
  • Vueではscopedをつけると擬似的にスコープをもたせることができる
    • ShadowDOMとは違う

Scoped CSSの留意点

コンポーネント命名規則

ディレクトリ構成

  • assetsの中にscssに変数とかmixin
    • 実態はcomponentsの中
  • 階層が深くなりすぎないようにした方がよさそう
  • 細かすぎる分割はパフォーマンスにも影響
  • 最初はシンプルに作って規模に応じて変更していくと良さそう

The Challenge of Web re-architecture using GraphQL and Apollo

  • @lightnet328さん

メルカリWebにリアーキテクチャ

  • 新しい技術で作り直してる
    • TS
    • Next
    • React
    • Apollo
    • GraphQL
  • ページごとに部分的に公開している

GraphQLとApollo

  • なぜGraphQL
    • スキーマはドキュメントより実装と乖離するリスクが小さい
    • クエリの可読性高い
  • なぜApollo Clients
    • リモートデータの取得管理を任せたい
    • キャッシュによってリクエストが減る
  • なぜApollo Server
    • BFFとしての役割
      • スキーマをフロントエンドのために整理
      • ロギング
      • 認証
      • 将来的にgRPCでマイクロサービスに接続
      • クライアントが1つのエンドポイントだけ知ってればよい

Practical tips for making a global EC site

  • @yayoc_さん

UNIQLO Global EC

  • 特徴
    • 22カ国
    • O2Oもサポート
    • 機能が国によって異なる
  • これまで
    • 国ごとに異なるアプリ
    • クライアントヘビー
  • これらを解決させるプロジェクト
    • 1つのコードで複数の国対応
    • パフォーマンスはやく
    • a11y
    • コンシューマだけでなく管理画面のUXも改善
  • ページによってSSR
  • 国別にリダイレクトリライト

グローバルサイト構築

URL構造

  • /:country/:language
  • countryなかったらCDNの国
  • languageなかったらAccespt-Languageの言語

SEO

  • GoogleBot以外も考慮
  • JSレンダリングしてくれなかったのでHTML返した方が無難(SSR)

CMS

パフォーマンス

  • 毎日WebPAgeTest/Lighthouseを国別で実行
  • Performance Budget
    • total 200kb
    • chunk 80kb
  • webpack-bundle-analyzer
    • バンドルファイル内の内訳を可視化

ローカライゼーション

  • i18n- webpack-plugin
  • エントリーポイントを分けている
  • ルーティングベースでコードスプリッティングしてるから余計なのは入らない
  • 一部プレースホルダーで出し分け
    • 単数系/複数形とか
  • 決済フローなんかは国によって異なったりするのでコンポーネント出し分けてる
  • minificationで不要なものは削除される

a11y

  • ビジネスサイドからの要件も強い
  • Lighthouseでスコアとるだけでなくそれ以外の項目もチェック
    • 画像説明
    • CSSなしで動くか

画像

  • 一般的に画像が大きいほどコンバージョンは高い
  • CDNでWebPに変換してサイズ圧縮
  • プレースホルダーおいてリフロー防ぐ
  • 遅延ロード

BFF

  • マイクロサービスへのAPIリクエストを束ねる
    • クライアントヘビーな実装軽減
    • クライアントが扱いやすいような構造に整形
  • キャッシュ
    • max-ageを見て設定
  • ロギング
  • HMAC認証をサポート